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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the agent knows this creates state. The description adds the useful framing that this is a manual override to auto-discovery, but says nothing about persistence, session lifetime, or what happens on duplicate adds.

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, action first, rationale second. No filler and nothing buried.

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

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

Simple 2-parameter tool with full schema coverage, annotations, and an output schema, so return values need not be explained. The description gives enough to call it correctly; only edge-case behavior (duplicate sessions, failure modes) is unaddressed.

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

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

Schema coverage is 100% and both parameters are documented with defaults in the schema. The description only names host/port generically, adding no format or valid-range 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?

States a specific verb (add) and resource (a Maya session) plus the scoping detail of host and port. It is clearly distinct from list_sessions and the scene_* tools, though it never names a sibling explicitly.

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

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

Gives a concrete when-to-use: 'when auto-discovery doesn't find your Maya session, or to connect to a Maya instance on a specific port.' The fallback condition relative to auto-discovery is spelled out, though no other tool (e.g. list_sessions) is named as an alternative.

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

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

The annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds rich behavioral context beyond those flags: download safety (https-only, size caps, md5 verification), cache location, local FBX import with meter handling, automatic texture wiring rules, polycount gating, grouping, and bbox/metadata reporting.

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 tool's purpose. The pipeline is expressed as a compact arrow chain, and the idempotency behavior is stated without wasted words. Every sentence 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?

Given a mutation tool with an output schema, annotations covering safety and idempotency, and full parameter descriptions, the definition is complete enough for an agent to call it correctly. The pipeline, safeguards, and idempotency contract are all disclosed.

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 adds meaning beyond the schema by directing agents to resolve asset_id via asset_search and by explaining that over-limit imports are deleted and rejected, which contextualizes max_polycount and allow_high_polycount.

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: 'Import a Poly Haven CC0 model into Maya.' It also explicitly names the sibling tool used to find ids ('asset_search'), so an agent can distinguish this import tool from the search tool immediately.

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

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

Provides clear usage context: find ids via asset_search first, then use this tool to import. It also specifies when to set force=True by explaining the default idempotent behavior and what happens on repeated calls.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the exact remote endpoint queried and the fact that execution is host-side, i.e. it makes an outbound HTTP call with no Maya session required. Rate limits or error behavior from the remote API are not mentioned.

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

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

Three short sentences, front-loaded with the verb and resource, then endpoint and safety traits. No filler or repetition of the schema.

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

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

An output schema exists, so return values needn't be spelled out; the description still notes that matching asset metadata is returned. Combined with full schema coverage and complete annotations, an agent has enough to invoke it correctly, with only the handoff to asset_import 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 query, limit and asset_type are already fully documented in the schema, including defaults and the asset_import caveat for models. The description adds nothing about parameter semantics, 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 (Search) and resource (the Poly Haven CC0 asset index) and immediately scopes it as host-side with no Maya dependency, which separates it from the Maya-bound siblings. It does not explicitly name asset_import as the alternative for actually pulling assets into the scene, so sibling 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 phrase 'pure lookup' and 'no Maya needed' implies the discovery use case, but the description never states when to prefer this over asset_import or what to do after finding an asset. Usage is inferable 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?

Annotations already disclose the safety profile: not read-only, not idempotent, not destructive, closed-world, so the agent knows this mutates scene state and cannot be safely retried. The description adds the shot-type vocabulary but says nothing about whether the new camera persists across sessions, whether it is undoable via scene_rollback, or that a Maya session is involved.

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

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

Two short sentences, front-loaded with the action and scope, with the value list consigned to the second sentence. No filler or repetition.

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

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

With an output schema present the description need not explain returns, and the annotations carry the safety profile, so the remaining gap is small: it does not mention that a Maya session is required or how this relates to camera_orbit when adjusting an existing camera. Adequate for a 6-param creation tool.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds the enumerated set of valid shot_type values (extreme_wide, wide, medium, close, extreme_close, over_shoulder, bird_eye, low_angle) that the schema omits — the schema only says 'Shot type (default "medium")' with no enum. That is genuine added meaning over the schema.

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

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

States a specific verb and resource ('Create a camera') plus its scope ('positioned for a specific shot type'), which is clearer than a bare 'create camera'. It does not name or contrast the closest sibling (camera_orbit) or any other scene_* tool, so an agent gets a clear action but no explicit sibling differentiation.

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 shot-type list implies the intended workflow (framing a shot within a Maya scene), but there is no explicit when-to-use, no stated prerequisites (e.g. that a session/target must exist), and no contrast with camera_orbit for moving an existing camera.

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, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral — notably it does not warn that repeated calls create additional cameras (non-idempotent) or describe the resulting animated camera's state.

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

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

A single tight sentence with no wasted words, front-loading the action and the key differentiator (orbiting with animation). Slightly under-specified rather than bloated.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a non-idempotent creation tool with five parameters, the description should at least state prerequisites or the effect of repeated invocation, which it omits.

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

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

Schema description coverage is 100%, so all five parameters (name, center, frames, radius, session_key) are already documented in the schema. The description adds no syntax, units, or constraint detail beyond that 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 and resource: create a camera, with the distinguishing qualifier that it orbits a point with animation. This separates it reasonably well from the sibling camera_create, but it never names that sibling or clarifies the boundary 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as camera_create. An agent must infer from the name alone when an orbiting camera is preferable to a static one.

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 non-idempotent, so the safety profile is conveyed structurally. The description adds nothing beyond that – it does not warn that arbitrary code runs with full privileges in a live session, that effects are irreversible, or how result handling works.

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

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

A single short sentence with no filler, and the core action is front-loaded. It is efficient, though arguably terse to the point of under-specification for a destructive tool.

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

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

For a destructive, non-idempotent tool with no output schema, the description should explain that return values depend on result_type and that the code mutates live scene state. None of this is covered, leaving significant gaps for safe 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 100%, so all three parameters including the result_type enum-like modes are fully documented in the schema. The one-line description adds no parameter meaning beyond that, which is the baseline 3 case.

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 (Execute) and resource (Python code) plus the execution context (a Maya session). It is clear what the tool does, but it does not distinguish itself from siblings like write_module, which also implies code authoring/execution.

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 guidance, no exclusions, and no mention of alternatives such as the higher-level scene_* inspection tools. The agent must infer that this is the escape hatch for arbitrary operations.

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 safety profile is covered. The description adds real value beyond them: the polling cadence recommendation and the SessionManager's background scanning behavior, which an agent would not infer from annotations. It does not disclose latency or result freshness guarantees.

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

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

Front-loaded with the core purpose and the operational note is well placed, but the eight-line enumeration of return fields largely duplicates what the output schema already provides, adding length without added value.

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

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

For a zero-parameter read tool with an output schema and full annotations, the description covers the remaining agent-relevant unknowns (polling cadence, background scanning, empty-list recovery). Nothing critical is missing, though freshness/latency of the session list is unaddressed.

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, which is the baseline-4 case. The enumerated fields describe output, not inputs, so there is no parameter semantics to clarify, and none is missing.

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

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

States a specific verb and resource ('List all active Maya sessions') with explicit scope ('active'), which cleanly separates it from add_session and the scene_* siblings. An agent can identify the tool's job 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?

Gives concrete usage context (poll every 10-30 seconds to detect new/removed sessions) and a fallback path (call maya_setup_guide() when the list is empty). It lacks explicit 'when not to use' or named alternatives such as add_session, 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?

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is conveyed structurally. The description goes further by naming the artifact it mutates ('auto-installation of userSetup.py') and the fallback-instruction behavior, which tells the agent this tool writes to disk rather than only probing. It does not, however, flag that uninstall can delete files.

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 sentences, no filler: identity first, then the routing condition, then the capability list. Each sentence carries distinct information and the trigger is front-loaded.

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

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

An output schema exists, so return values need not be explained, and the four action modes are enumerated in the schema. The description supplies the trigger and the artifact being modified, which is sufficient for correct invocation; only the destructive-delete nuance of uninstall is left unstated.

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 six parameters (port, action modes, confirm, dry_run, target_version, remove_empty_file) are already fully documented in the schema. The description adds no parameter-level 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?

Opens with a specific resource and two capabilities: 'Maya connection setup guide and diagnostics.' An agent can immediately see this is the troubleshooting/onboarding tool rather than a scene or session tool. It stops short of 5 because the write actions (install/uninstall of userSetup.py) that distinguish it from a pure read-only diagnostic are not surfaced in the lead sentence.

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 an explicit trigger ('when list_sessions returns empty') and a second condition ('setting up Maya MCP for the first time'), naming the sibling tool whose output selects this one. This is precisely the routing guidance an agent needs.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds only the output shape (0-100 score, S/A/B/C/D/F grade, suggestions), which is redundant given the output schema exists, and says nothing about cost, latency, or session requirements.

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

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

Front-loaded with the core claim and then a clean numbered breakdown of dimensions. Slightly wasteful: the opening line and the second line restate the same '5 dimensions' claim, which could be merged.

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

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

With an output schema present, the return values need not be described, and the dimension list plus annotations give an agent enough to call it. The only real gap is the absence of routing guidance against sibling analysis tools.

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

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

Schema description coverage is 100%, so both parameters (format, session_key) are fully documented in the schema. The description adds no parameter meaning beyond that, 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 (analyzes) and resource (scene aesthetics) and enumerates the five design dimensions, so an agent knows exactly what comes back. It does not, however, distinguish itself from plausible siblings like scene_review, scene_validate, or scene_measure, which an agent could easily confuse it with.

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

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

The description never says when to reach for this tool versus scene_review, scene_measure, or scene_validate. There is no context, prerequisite, or exclusion stated — only a statement of capability.

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, and closed-world behavior. The description adds workflow timing and verification intent, but does not disclose failure semantics, auth needs, or other behavioral details beyond what annotations and the output schema provide.

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

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

Three short sentences, front-loaded with the core action. There is minor redundancy between verify and confirm and the unexplained ICEV jargon, but no wasted padding.

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

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

For a 3-parameter verification tool with rich annotations and an output schema, the description covers purpose, timing, and workflow role. It leaves sibling differentiation unstated, but is otherwise complete.

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

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

Schema description coverage is 100%, and the expectations parameter format and supported properties are fully documented in the schema. The description adds no additional parameter meaning, so baseline 3 is appropriate.

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

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

Names a specific action and resource: verifying scene state against expected values. It does not distinguish itself from siblings like scene_validate or scene_inspect, 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?

Explicitly says to use this after modifications to confirm the desired state, and ties it to the VERIFY step of the ICEV workflow. It provides clear context but names no alternatives or when-not-to-use conditions.

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/openWorld/idempotent/destructive flags; the description goes well beyond them, disclosing that checkpoints carry no undo history, that same-name saves are rejected unless overwrite=True, that the old file is preserved via rename, that references are flattened, and even naming the return fields (original_file_status, scene_rebound_to).

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?

Well front-loaded: the core action leads, then naming/overwrite rules, then honest bounds. Dense but each sentence carries information; the parenthetical 'Honest bounds:' framing is slightly editorial but useful rather than wasteful.

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 the full picture for a mutation-style tool: scope, file placement, failure modes (same-name rejection), preconditions (untitled scenes), and the limitations an agent needs (no undo history, flattened references, one scene file per session). Even though an output schema exists, the returned status fields are described usefully.

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 already 100%, so the baseline is 3, but the description adds real meaning beyond the schema by explaining the untitled-scene requirement for `name` and the preserve-via-rename semantics of `overwrite`. The session_key parameter remains unexplained in the description.

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

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

States a specific verb+resource ('Save a real scene snapshot (exportAll of in-memory state)') and immediately distinguishes it from the sibling scene_snapshot by noting that one is for rebuilding context after rollback. Also differentiates from scene_viewport_snapshot by specifying a self-contained .ma written to checkpoints/.

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?

Explicit conditions are given: an explicit name is required on untitled scenes, overwrite=True is needed to replace an existing checkpoint, and scene_snapshot should be used after scene_rollback. Both when-to-use and when-to-use-the-alternative are covered.

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 (readOnly, idempotent, non-destructive), so the bar is low. The description adds genuinely new behavioral context: results vary by scene type, with untitled scenes resolving to workspace ad-hoc snapshots and an adhoc flag per entry. It stops short of describing entry shape or ordering, but this is solid added value over 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 short sentences with no filler, and the core action is front-loaded before the source-dependent detail. The line-wrapped second sentence is slightly awkward but not wasteful.

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

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

With an output schema present, return values need not be explained, and the annotations carry the safety profile. The description covers the one non-obvious behavior (scene-type-dependent sources) and is adequate for this low-complexity, single-optional-parameter tool.

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

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

Schema description coverage is 100% for the single optional session_key parameter, so the schema does the documentation work and baseline 3 applies. The description adds no extra meaning about session_key or whether it is needed for the lookup.

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

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

States a specific verb and resource: 'List all saved checkpoints for the current scene state.' It further distinguishes two data sources (saved scene <scene_dir>/checkpoints vs. untitled workspace ad-hoc snapshots), but never names the sibling tools it is *not* (e.g. scene_checkpoint for creating, scene_rollback for restoring), so differentiation from siblings is left to inference.

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

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

Usage is implied by the read-only listing verb, but there is no explicit when-to-use, when-not-to-use, or alternative routing (e.g. 'to create a checkpoint use scene_checkpoint; to restore use scene_rollback'). An agent must infer its place in the checkpoint/rollback workflow.

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, and destructiveHint=false, so the safety profile is covered. The description adds the non-spatial/API-level framing, but does not add behavioral details beyond the annotations and schema, such as truncation or attr_not_found abort behavior, which appear only in the schema.

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

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

The description is two compact sentences/paragraphs, front-loaded with the core capability and immediately followed by the sibling boundary and intended use. There is no 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?

Given the rich 100%-covered schema and the presence of an output schema, the description is complete enough: it explains the tool's conceptual output (node type, per-attribute metadata, connection wiring), its scope, and its boundary against scene_inspect. Return-value details are appropriately left to the output schema.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters thoroughly, including defaults, budgets, and abort behavior. The description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description states a specific capability: API-level self-description of ONE node, explicitly marked as not spatial. It distinguishes the tool from its closest sibling by contrasting scene_inspect's WHERE with scene_describe's WHAT.

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

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

It gives an explicit boundary against scene_inspect and states the intended downstream use: composing accurate execute_code/setAttr/connectAttr calls against real names. This is exactly the when-to-use guidance an agent needs to choose between scene_describe and other scene-inspection 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?

Goes well beyond the annotations: discloses that prompt=False is forced to avoid a modal hang, that the selection set is restored and the modified flag untouched, and that overwrite=True irrecoverably replaces the target file. Flagging the destructive edge case against destructive_hint=false is exactly the kind of nuance 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?

The core action and safety caveat are front-loaded, and parenthetical asides are informative rather than filler. Slightly dense with nested qualifications, but every sentence carries operational weight.

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

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

With an output schema present, the description needn't explain return values, and it covers everything else an agent needs: format support and limits, prompt suppression, selection/state preservation, and the irrecoverable-overwrite risk.

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 already 100%, but the description adds real value beyond it by listing the accepted formats and explaining why Alembic is excluded via the cmds.file surface. It also reinforces the overwrite/path semantics, though most per-parameter detail lives in the schema.

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

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

States a specific verb (Export) and resource (the Maya scene or named objects) with the destination (a local file), and no sibling tool competes for this function. An agent can identify the operation immediately 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?

Gives clear operative context: supported formats (fbx, obj, usd) and an explicit exclusion (Alembic is not supported, with the reason). It doesn't map to an alternative sibling, but none exists, so the routing guidance is adequate for the domain.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds some behavioral context by enumerating what is returned (transform, BBox, material, mesh stats, neighbors), but that overlaps with the existing output schema, so net added value is modest.

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 purpose and followed by return contents; no filler. The return-value sentence is somewhat redundant given the output schema, which keeps it from 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?

For a read-only tool with full schema coverage and an output schema, the definition covers the essentials. It is nonetheless incomplete on the one thing structured fields cannot supply: how it differs from sibling inspection tools such as scene_describe.

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 4 well-documented parameters, so the baseline is 3. The description only loosely echoes 'target' (object or zone) and 'include_neighbors' (nearby objects with distances) without adding syntax, format, or 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?

States a specific verb+resource: 'Deep inspection of a specific object or zone', and scopes it as deep/detailed versus superficial. However, it does not distinguish itself from close siblings like scene_describe, scene_nodes, or scene_measure, leaving the agent to guess 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite a crowded sibling set (scene_describe, scene_nodes, scene_measure, scene_assert). Usage is only implied by the phrase 'specific object or zone'.

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, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context such as session requirements, error behavior, or whether it mutates any state. It neither contradicts nor enriches what the annotations provide.

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

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

A single, front-loaded sentence with no wasted words. It immediately conveys the core purpose without filler. Brevity is appropriate for the core description, as structured fields handle details.

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

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

Given the tool's complexity (5 parameters, multiple measurement modes) and the rich structured data (100% schema coverage, output schema present), the description is minimally adequate. It does not mention the available modes or the distinction from siblings, leaving the agent to rely entirely on schema and annotations.

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 five parameters fully documented in the input schema (including mode options and format). The description adds no parameter meaning beyond what is already in 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?

The description states a specific verb and resource: 'Measure spatial relationship between two objects.' This is clear and avoids tautology. However, it does not differentiate this tool from siblings like scene_inspect or scene_assert, which could also involve scene analysis.

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

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

No guidance is given on when to use this tool versus alternatives. The description simply defines the function and does not mention any conditions, prerequisites, or exclusions. An agent must infer usage from the name and schema 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the disclosure that results are bounded and that has_more/next_cursor signal a truncated list. That is genuine pagination behavior an agent needs. It does not, however, discuss session/auth prerequisites despite exposing session_key.

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, with the scope claim front-loaded ahead of the sibling contrast. The phrasing 'pages honestly' is a touch colloquial and the boundary paragraph carries mild abstraction, but nothing is wasted or buried.

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

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

With an output schema present, return values need no explanation, and all eight parameters are schema-documented. The description supplies the sibling boundary and pagination caveat, leaving it nearly complete for a read-only 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?

Schema description coverage is 100%, so all eight parameters (type inheritance, limit cap, cursor validity, glob pattern, dag_only) are already documented in the schema. The description adds no parameter-level detail beyond what the schema 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?

States a specific verb and resource ('bounded enumeration of scene nodes') and immediately narrows scope with 'including non-DAG nodes'. It explicitly distinguishes itself from scene_snapshot, so an agent can route between the two 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?

Names the sibling alternative (scene_snapshot) and states the condition that selects each: snapshot is the once-per-workflow spatial overview, scene_nodes is the name-discovery complement that surfaces nodes a spatial view never shows. The routing decision is explicit rather than 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 declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description frames the tool as analysis/planning, which aligns with the non-destructive hint, and it details the scope of what gets checked. It doesn't disclose that the auto_fix parameter can mutate the scene, leaving a gap the annotations don't fully cover.

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 opening sentence is front-loaded and the bullet list is scannable, with each bullet earning its place by naming a distinct capability. Slightly verbose, but the structure pays for the length.

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

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

An output schema exists, so return values needn't be explained, and the description thoroughly covers what the tool analyzes and produces. The only real gap is the absence of routing guidance relative to the many sibling scene tools.

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

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

Schema description coverage is 100%, so parameters (format, auto_fix, objective, session_key) are fully documented in the schema, setting the baseline at 3. The description only loosely echoes the objective parameter with 'Supports natural language objectives' and adds no new syntax or format detail.

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 ('scene planning') and enumerates concrete capabilities (organization validation, zone analysis, layout suggestions, conflict prevention, action plan). This distinguishes it from siblings like scene_validate and scene_inspect, though it doesn't explicitly name which sibling to prefer.

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 offers implied guidance via 'blockout-first methodology' and 'before committing to detailed modeling,' giving a sense of when in the workflow to use it. However, it never states when to choose this over scene_validate, scene_review, or scene_aesthetics, nor any 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?

Goes well beyond the readOnlyHint/idempotentHint annotations: it discloses that the camera flag switch is instantaneous but NOT undoable, that the net state is restored on every path including failure, that the timeline may visibly jump, that no viewer window opens, and that only a killed process can skip the restore. This is exactly the kind of side-effect detail annotations cannot carry.

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 one-line purpose is front-loaded, followed by a numbered disclosure list where each item carries distinct information. The list is long but nearly every entry earns its place; a small amount of trimming is possible but nothing is obviously wasteful.

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 a fairly complex side-effecting operation, the description covers the session requirement, the state-restoration contract, and the failure behavior thoroughly. It stops short of describing the returned image/metadata payload, though it does point at 'the returned metadata' as the source of truth for size.

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 parameter meaning is already fully documented by the schema, establishing a baseline of 3. The description adds no parameter semantics of its own and in fact references a 'viewer=False' option that does not appear in the input schema, which is mildly confusing.

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 ('Single-frame playblast preview from a camera') with the scope qualifier 'clean, no HUD', so an agent knows exactly what artifact is produced. It does not, however, differentiate itself from the closely named sibling scene_viewport_snapshot, which is the main ambiguity an agent would face.

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 'GUI sessions only - headless sessions get a structured gui_session_required error' line is a genuine when-not condition, telling the agent the call will fail in headless contexts. It stops short of naming an alternative tool for the headless case, so it is clear context rather than full routing guidance.

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

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

Annotations already establish that this is a read-only, non-destructive, idempotent, closed-world operation. The description adds useful behavioral context by enumerating the audit checks and stating that it returns a 0-100 score plus a detailed issue list. It does not add details about cost, latency, or failure modes, but those are not critical here.

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

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

The description is front-loaded with the core purpose and followed by a compact list of checks, a return-value summary, and a usage recommendation. It is efficient overall, though the check list partly duplicates the schema's enum-like options.

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 annotations covering the safety profile and an output schema available, the description does not need to explain return formatting in depth. It provides enough context about scope, checks, output, and timing to invoke the tool correctly, but it could be stronger if it distinguished this tool from similar validation siblings.

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

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

Schema description coverage is 100%, so the input schema already documents the checks, format, and session_key parameters. The description lists the available check categories, which reinforces the checks parameter, but it does not add syntax or behavioral meaning beyond what the schema provides.

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

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

The description states a clear verb and resource: a comprehensive scene audit that reviews spatial integrity, overlaps, zones, aesthetics, constraints, orphans, naming, components, conflicts, lighting, and organization. It clearly distinguishes itself as a broad quality review rather than a single-purpose check, though it does not explicitly differentiate from sibling tools such as scene_validate or scene_assert.

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

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

It gives a clear usage context: 'Use this after any major scene modification to verify quality.' This tells the agent when to call it, but it does not state when not to use it or explicitly compare it with alternative validation tools like scene_validate or scene_assert.

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 cover the safety profile; the description supplies the failure model (aborts if the auto_before_rollback export fails), the escape hatch and its reported result value (safety_snapshot="skipped_by_user"), the null scene_rebound_to case, and the loss of undo history. That is exactly the beyond-annotations context this dimension rewards.

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?

Purpose is front-loaded in sentence one, then behavior, failure mode, and follow-up in a tight four-sentence block with no filler. The S1/S2 labels are unexplained internal jargon that costs a little clarity for no gain.

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 state-mutating tool with full schema coverage and an output schema, the description covers everything an agent still needs: failure/abort behavior, the escape hatch, edge-case scene states, and the required follow-up call. Nothing material 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%, so baseline is 3, but the description genuinely deepens discard_current_state ('pass ... to escape', with the resulting safety_snapshot value) and explains the untitled-scene implication for filename/rebinding. It stops short of adding format detail for session_key.

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 first sentence states a specific compound action (open a checkpoint and rebind the scene) with a resource, which is immediately distinguishable from siblings like scene_checkpoint (creates) and scene_snapshot (captures). The two-outcome behavior (S2 vs S1) further pins down what the call does in the normal case versus untitled scenes.

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

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

It gives concrete conditions: pass discard_current_state=True when the safety snapshot fails, and call scene_snapshot afterwards to rebuild undo context. Edge cases (untitled scenes, ad-hoc snapshots) are called out explicitly. It lacks an explicit statement of when to prefer this over scene_checkpoint/scene_snapshot beyond the follow-up pointer, so it falls just short of 5.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuinely useful context beyond them: it returns ALL objects with positions/sizes/types and should be called once per workflow, which tells the agent about output breadth and the cost of repeated calls.

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

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

Three short sentences, front-loaded with the core verb+resource, then return contents, then invocation cadence. No filler or redundancy.

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

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

With an output schema present, the description needn't enumerate return fields and it correctly gives breadth and cadence guidance instead. Only minor gaps remain, such as noting multi-session behavior when session_key is omitted.

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 all three parameters carry their own descriptions (detail levels, format options, session key auto-selection). The description adds no parameter syntax or format 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 and resource ('Get a complete spatial overview of the current Maya scene') and enumerates the returned content (positions, sizes, types). It is distinguishable in spirit from siblings like scene_nodes or scene_viewport_snapshot, but never names an alternative to sharpen 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?

'Call this once at the start of each workflow to establish spatial awareness' gives a clear invocation context and frequency. It stops short of stating when not to use it or which sibling to prefer for narrower queries.

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 covered. The description adds useful context by enumerating the violation classes it detects (clearance, object limits, overlaps, height), but says nothing about how violations are reported or whether validation is non-blocking.

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 waste, and the core action is front-loaded before the enumeration of checked conditions. Each sentence 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?

Output schema exists, so return values need not be explained, and annotations cover the read-only/idempotent behavior. The description adequately frames a constraint-validation tool; the only real gap is routing guidance relative to sibling validators.

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 rules JSON format, the five rule types, the format enum, and the session_key are already fully documented in the schema. The description contributes no additional parameter semantics, which matches the baseline 3 when the schema carries the load.

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

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

States a specific verb+resource ('Validate scene') and scopes it to spatial constraints, with concrete examples of what is checked. It does not differentiate itself from closely related siblings like scene_assert, scene_check, or scene_measure, so an agent cannot tell which validation-style tool to pick without reading 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?

No statement of when to use this tool versus scene_assert, scene_check, scene_measure, or scene_inspect, and no prerequisites or exclusions. Usage has to be inferred entirely from the name and the rule types listed.

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 (read-only, idempotent, non-destructive), so the bar is lower, yet the description adds real context: the GUI-only constraint, the specific error surfaced in headless mode, and the forced refresh that guarantees a current frame. It stops short of describing the return envelope, but the WYSIWYG/HUD caveat is a genuinely useful behavioral disclosure.

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

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

Front-loads the action in the first line, then qualifies with the GUI constraint. The 'That is a feature' sentence is slightly editorial but earns its place by preempting an agent wondering why HUD/ornaments appear in the shot.

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 capture tool with full schema coverage and no output schema, the description covers the key operating constraint and the composition of the returned image. It is close to complete; only the return/pagination envelope and sibling routing are unstated.

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 format, quality and max_size are already fully documented with defaults and trade-offs. The description adds nothing about parameters, which is the correct baseline-3 outcome when the schema carries the load.

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

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

States a specific verb and resource (capture the active viewport as an image) with a clear WYSIWYG qualifier. It does not differentiate itself from close siblings like scene_snapshot or scene_render_preview, leaving the agent to infer which capture tool fits which case.

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?

Names a definite when-not condition: GUI sessions only, with headless sessions returning a gui_session_required error. It does not name an alternative for clean/render captures (e.g. scene_render_preview), so routing among the snapshot siblings is still 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 destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds the useful 'virtual' qualifier, implying the module does not persist to disk, which is genuine context not in the annotations. It does not state what overwrite destroys or how the module interacts with the session lifecycle.

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

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

A single, front-loaded sentence with no filler or redundancy. It is efficient, though arguably too terse for a destructive write tool.

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

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

An output schema exists, so return values need not be described, and annotations plus full schema coverage carry the mechanics. However, the description omits the execute_code boundary and any session prerequisite, which are the gaps an agent actually needs filled for this 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 name, code, overwrite, and session_key are fully documented in the schema including the dotted-path behavior and overwrite semantics. The description adds nothing beyond that, so the baseline 3 is correct.

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 verb+resource: 'Create a virtual Python module in a Maya session.' An agent understands it defines in-memory Python code inside a session. It does not differentiate itself from the nearby execute_code sibling, which is the most likely point of confusion.

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 guidance, no prerequisites, and no comparison to execute_code, which is the obvious alternative for injecting Python into a session. The agent must infer the distinction from the name alone.

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