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?

The annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, but the description adds substantial context beyond them: it specifies that a camera and animation curves are created, that the scene is marked dirty, that each call adds another camera, and that an active Maya session is required. This is exactly the kind of operational side-effect detail 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?

It is three short, front-loaded paragraphs: purpose first, then side effects, then boundary. Every sentence carries distinct decision-relevant information with no repetition 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?

With annotations covering the safety profile, a full input schema, and an output schema handling return values, the description supplies the remaining decision-critical facts: side effects, non-idempotence, session requirement, and sibling disambiguation. Nothing needed to call the tool correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter including center, frames, radius, name, and session_key. The description adds no parameter-level meaning beyond that, so the 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?

The description states a specific verb and resource: 'Create an orbiting camera with turntable animation around a point.' It also distinguishes the tool from its sibling camera_create by defining the boundary condition (static framing vs animated orbit), so an agent can choose correctly 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?

It explicitly names the alternative (camera_create) and the condition that selects this tool: use camera_orbit only when an animated orbit is needed. This is direct when/when-not guidance with a sibling 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?

Adds substantial context beyond annotations: runs with full session privileges, execution is irreversible and cannot be undone, modifications do not register an automatic undo chunk, and the return value shape is governed by result_type. This is exactly the behavioral detail an agent needs for a destructive code-execution tool.

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

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

Front-loads purpose, then behavior, irreversibility, return handling, and session requirement. Every sentence adds a necessary operational detail 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 dangerous arbitrary-code tool with no output schema, the description covers execution scope, privileges, irreversibility, undo behavior, return envelope control, and session requirements. An agent has enough context to invoke it correctly and cautiously.

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 explains code, result_type, and session_key in detail. The description only notes that result_type governs the return envelope, adding little beyond the structured field documentation. 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?

States a specific verb and resource: execute arbitrary Python or MEL code in an active Maya session. This distinguishes it from all scene_* siblings, which operate on scene data rather than arbitrary code 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?

Provides a clear prerequisite: an active Maya session, discoverable via list_sessions. It does not explicitly name alternatives or when not to use this tool versus scene_* tools, but the intended context 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, 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 covered. The description adds the output shape (0-100 score, letter grade, improvement suggestions), but no session/auth requirements, latency, or failure behavior, and the return detail is largely redundant given an 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?

Front-loads the purpose, then uses a scannable numbered list for the five dimensions, closing with return info and the boundary rule. The dimension detail is somewhat verbose for tool selection but earns its place by conveying analysis depth; 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?

An output schema exists, so return values needn't be explained again, and the description still summarizes the scoring model. Combined with annotations covering safety and a fully described two-param schema, the definition is essentially complete, missing only minor context like prerequisites or session handling.

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 already documented in the schema. The description adds nothing about the format enum or session_key semantics, so the baseline 3 for fully-covered schemas 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 ('Analyzes scene aesthetics across 5 professional design dimensions') and enumerates exactly what those dimensions are. The Boundary section explicitly disambiguates it from scene_review, so an agent can distinguish it from siblings without opening a schema.

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

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

The Boundary statement gives an explicit routing rule: use scene_aesthetics for deep visual design theory/artistic harmony, scene_review for a broad multi-system health audit. That is clear alternative-selection guidance, though it stops short of stating trigger conditions like 'call this after placing assets' 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the workflow role ('VERIFY step of the ICEV workflow') and the disambiguation boundary, which is genuine context beyond the structured fields. It does not explain failure semantics (what happens on mismatch), but the output schema carries return details.

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 core purpose in one sentence, then usage, then workflow role, then a clearly labeled boundary. Every sentence earns its place with no waste.

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 assertion tool with full schema coverage and an output schema, the description supplies the purpose, usage context, and sibling routing. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents expectations, format, and session_key in detail. The description only alludes to 'expected values for named objects', adding no syntax or format detail beyond the schema. 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?

States a specific verb ('Verify') and resource ('scene state') with the scope 'matches expected values'. The boundary sentence explicitly distinguishes it from the sibling scene_validate, so an agent can route correctly without opening a schema.

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

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

'Use this after modifications to confirm the scene is in the desired state' gives an explicit when-to-use, and the boundary note gives an explicit when-not (relational spatial checks across zones -> scene_validate). Nothing 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 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 cover the safety profile (readOnly, idempotent, non-destructive, not open-world), but the schema text adds contract-level behavior beyond that: over-budget output is truncated and disclosed via attrs_truncated/total_count rather than silently dropped, a missing named attr aborts the whole call with attr_not_found, and include_values may trigger costly DG evaluation. These are real behavioral traits not derivable from the 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?

Front-loaded with the core purpose in the first clause, then a compact three-way boundary. Dense but every clause routes or clarifies; the parenthetical '(not spatial)' and the sibling contrast both earn their place. Slightly prose-heavy for the payload.

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 and annotations are rich, so return-value explanation is not required. Given the routing ambiguity this tool sits in among scene_* siblings, the boundary paragraph supplies exactly the missing orientation an agent needs to call it 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 the schema already documents node, attrs, limit, include_values, include_connections and session_key in detail. The top-level description itself adds no parameter meaning beyond the boundary framing, 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 ('API-level self-description of ONE node') and immediately disambiguates the concept ('not spatial'). It explicitly distinguishes itself from scene_inspect (WHERE) and scene_nodes (candidate names), so an agent can pick the right tool 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?

The Boundary paragraph gives explicit when-to-use framing and names two sibling alternatives with their distinct jobs. It also names downstream tools this output feeds (execute_code/setAttr/connectAttr), tying usage to intent.

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 readOnly/idempotent/non-destructive/non-openWorld, so the safety profile is covered. The description adds that inspection surfaces transform, BBox, material, mesh stats and optional neighbor distances, which sets expectations about scope and depth. It stops short of noting cost or size limits for deep inspection, so not a 5.

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

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

Front-loaded purpose, then return contents, then the disambiguation boundary — a logical order with no filler. Every sentence carries routing or expectation-setting information.

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

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

With a full input schema, a present output schema, and rich read-only annotations, the description only needs to cover scope and disambiguation, and it does both. Nothing required to invoke the tool correctly is missing.

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

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

Schema description coverage is 100%, so all four parameters (target, format, session_key, include_neighbors) are already documented in the schema. The description only indirectly echoes the neighbor option ("optionally nearby objects with distances") without adding format or session semantics. Baseline 3 for full schema 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?

States a specific verb+resource ("Deep inspection of a specific object or zone") and immediately enumerates what it returns. The Boundary section explicitly distinguishes it from scene_snapshot and scene_describe, so an agent can route 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?

The Boundary paragraph names the two most confusable siblings and characterizes each (broad whole-scene spatial overview vs API-level attribute metadata/types/wiring), giving an explicit selection rule. This is genuine when-to-use guidance rather than implied context.

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

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

Annotations already cover readOnly/idempotent/non-destructive, yet the description still adds real behavioral context: no undo checkpoint is created, an active Maya session is required, measurements are world-space AABBs (not mesh surface or origin), and units follow the scene's linear unit. The per-mode semantics of the signed clearance value and the bbox_overlap flag are unusually thorough for a mutation-free query tool.

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

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

Front-loaded with purpose, then usage, then semantics, then boundary — a clean hierarchy. It is long and the clearance-mode block is dense, but nearly every line carries decision-relevant information, so the length is mostly earned rather than 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?

Given an output schema exists, the description needn't enumerate return fields, and it instead supplies what the schema cannot: mode semantics, units, session prerequisite, and sibling boundaries. Nothing an agent needs to invoke or interpret this tool correctly is missing.

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

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

Schema coverage is 100%, but the schema for 'mode' merely says 'see the list above' — the description is the authoritative source for what each mode's number means, including the counter-intuitive signed clearance semantics and the details.clearances_xyz escape hatch. It also adds the unit caveat that applies to all returned distances.

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 opening sentence states a specific verb and resource ('Measure the spatial relationship between two objects'), and the Boundary paragraph explicitly distinguishes it from scene_inspect, scene_snapshot and scene_assert. An agent can identify the tool's niche without opening any schema.

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

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

It names the workflow stage (COMPUTE step of ICEV) and gives three concrete triggering situations (sizing a clearance before a move, proving interpenetration before a separation, getting axis detail behind a scene_validate overlap). The Boundary paragraph explicitly routes competing questions to other 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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds real behavioral context beyond them: it discloses pagination semantics (has_more/next_cursor signal truncation) and that the list surfaces dependency nodes a spatial view hides. It does not restate the hard cap or cursor-invalidation rules, but those live 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?

Front-loaded with the core definition before the boundary routing, and it is compact for the amount of disambiguation it packs in. A few phrases ('pages honestly', 'low-resolution spatial overview') lean rhetorical rather than informational, but nothing is redundant with structured fields.

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 described, and annotations cover safety. The description supplies scope, sibling boundary and pagination behavior for an 8-param list tool — the remaining gaps (cap details, cursor lifetime) are already 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 carries type/inherited, dag_only, limit, cursor, pattern and session_key semantics. The description's only added parameter meaning is the non-DAG node examples (materials, shadingEngines, tool nodes) that motivate dag_only, which is marginal. Baseline 3 applies 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?

States a specific verb (bounded enumeration) and resource (scene nodes), and immediately scopes it with 'including non-DAG nodes' — a distinction no sibling makes. The boundary paragraph names scene_snapshot and scene_describe so the agent can separate the three without opening a schema.

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

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

Explicitly routes: scene_snapshot is the once-per-workflow spatial overview, scene_nodes is the name-discovery complement for the API layer, and scene_describe is for attribute schema and connection inspection. When-to-use and the alternative for adjacent needs are both 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=false, idempotentHint=false and destructiveHint=false, carrying the safety profile. The description adds that output is forward-looking planning with 'actionable auto_fix reorganization', but never plainly states that auto_fix mutates the scene or which issues get changed, so it adds only moderate context beyond 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?

Front-loads the one-line purpose, then uses a scannable bullet list for capabilities and ends with the sibling boundary. Slightly long but every block serves routing or scoping; 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 an output schema present, return values need not be described, and the description covers purpose, methodology, and boundary disambiguation. Complete enough for a 4-param tool; what's missing is explicit disclosure of the mutation trigger, which the annotations partly cover.

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 four parameters fully. The description only loosely gestures at 'auto_fix reorganization' and 'natural language objectives', which map to existing parameters without adding format or behavioral 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 (planning) and resource (scene), then enumerates the concrete outputs (organization validation, zone analysis, layout suggestions, action plan). It explicitly distinguishes itself from the sibling scene_review, 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?

Gives a clear usage context ('validate organization and proportions before committing to detailed modeling') and names the alternative sibling scene_review with the condition that selects each. No explicit when-not-to-use case beyond the boundary statement, so a 4 rather than 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 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 declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds real value beyond that: the full breadth of the eleven checks and the 0-100 score plus detailed issue list, which tells the agent this is an aggregate audit rather than a single check. It stops short of disclosing cost/runtime, which matters for a tool that runs eleven passes, so 4 rather than 5.

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

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

The scope statement and result shape are front-loaded, and the boundary paragraph earns its space by doing the sibling disambiguation work. 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?

An output schema exists, so the description needn't spell out return fields, and it correctly limits itself to noting the score-plus-issues shape. The only gap is the absence of any hint about execution cost or latency for a full eleven-check audit, which would help an agent decide between this and the narrower scene_validate.

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 checks enum options are already documented per-parameter, so the baseline is 3. The description restates the check names (spatial, overlaps, zones, etc.) but adds no syntax, precedence, or cost implications for subsetting checks, and says nothing about the format parameter.

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 (audit/review) and resource (scene) and enumerates all eleven check dimensions it runs, plus the score range it returns. The boundary paragraph explicitly separates it from scene_validate and scene_aesthetics, so the agent can route 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?

Gives an explicit trigger condition ("after any major scene modification to verify quality") and names the two nearest alternatives with the precise scope each covers. Both when-to-use and when-not-when-to-use are present.

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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds scope ('ALL objects') and a workflow-placement rule, which is useful context, but it does not disclose anything about result size, latency, or behavior on empty scenes 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, front-loaded components: purpose, return shape, then boundary. Every sentence earns its place, and the disambiguation is placed last where it doesn't obstruct the primary action.

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

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

With a full output schema, clear annotations, and zero required parameters, the description supplies everything an agent needs — what it returns, when to call it, and how it differs from siblings. No material gap remains.

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% — detail levels, format options, and the session_key fallback are all documented inline in the schema. The description adds no parameter-level meaning beyond that, 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 ('Get a complete spatial overview of the current Maya scene') and immediately defines the payload ('structured description of ALL objects with positions, sizes, and types'). The Boundary paragraph explicitly distinguishes it from scene_inspect and scene_nodes, so an agent can route without opening sibling 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?

Gives explicit timing guidance ('Call this once at the start of each workflow to establish spatial awareness') and names the two alternatives with the conditions that select them (deep-dive inspection vs granular node discovery with pagination). Nothing 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 readOnly, idempotent, and non-destructive, so the description earns credit for adding behavior beyond them: no undo rollback checkpoint is created and an active Maya session is required. It does restate 'read-only' which the annotations already cover, slightly reducing the marginal value.

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

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

Front-loaded with the core action, then scope, then boundary. Well organized, though the non-destructive/no-checkpoint sentence overlaps with the annotation hints 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?

An output schema exists so return values need no explanation. The description covers what is checked, side-effect behavior, session prerequisite, and sibling boundaries — everything needed to invoke it 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 coverage is 100%, and the schema documents rules format, supported constraint types, format enum values, and session_key. The description adds no parameter-level detail 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?

States a specific verb (validate) and resource (scene) plus the scope of checks (clearance, object limits, overlaps, height). It explicitly disambiguates from scene_review and scene_assert, so an agent can distinguish it from siblings 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?

Gives explicit when-to-use routing: use this for constraint checks, use scene_plan with auto_fix=True for automated fixes, and the Boundary section names scene_review and scene_assert as the alternatives with their distinct roles. Nothing 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 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 declare destructive=true and idempotent=false, but the description adds substantial context beyond them: modules are in-memory and do not persist across restarts, existing modules are protected unless overwrite=True, and injection targets sys.modules. This is exactly the kind of non-obvious behavior an agent needs before a destructive write.

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 with the core action first, then constraints, then a boundary statement. Slight redundancy between 'in-memory' in the opening sentence and 'virtual and in-memory' in the third, but overall tight and scannable.

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 session-scoped write tool, the description covers persistence, overwrite protection, auth/session requirement, and sibling routing, and an output schema exists so return values need not be explained. Nothing essential is missing.

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

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

Schema description coverage is 100%, so all four parameters (including overwrite semantics and dotted-path names) are already documented. The description restates overwrite behavior but adds no new syntax or format detail beyond the schema, which is the correct 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+resource: 'Create a virtual in-memory Python module' and clarifies it injects functions into sys.modules. The boundary paragraph explicitly distinguishes it from execute_code, so an agent can route 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?

Explicit when-to-use ('define reusable libraries and helper functions') vs alternative ('execute_code for one-shot imperative execution or expression evaluation'). Also states the prerequisite of an active Maya session.

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