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

With no annotations, the description carries the full behavioral burden. It usefully discloses that an image is returned and that a reusable path is provided (implying a file is written to disk), but it omits whether the operation is side-effect-free on the scene, whether it can fail on headless sessions, or any cost/latency considerations.

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 paragraphs with the core action front-loaded and no filler. The second sentence about the returned path earns its place, though it slightly overlaps with the output parameter's schema description.

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

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

There is no output schema, so the description must cover the return value; it does state that both an image and a reusable path are returned. Combined with 100% schema coverage, an agent has enough to call it correctly, leaving only minor gaps around failure modes.

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 camera, output, and session_key parameters are already fully documented in the schema (including defaults and examples). The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Screenshot the Maya viewport and return the image'), making the tool's function immediately clear. It does not, however, distinguish itself from the sibling 'view_image' tool, so an agent must infer the boundary between capturing and viewing.

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

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

It gives clear context for use ('visually check modeling progress before/after making changes'), which is actionable guidance. It stops short of naming when-not-to-use or pointing to alternatives such as view_image or get_scene_info, so it is clear but not exhaustive.

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

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

With no annotations provided, the description carries the full behavioral burden, yet it only restates the resource being created. It does not disclose mutation semantics such as where the node is added (current scene), whether it targets the active session, or any undo/permission behavior for an operation that clearly mutates scene 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 front-loaded sentence that names the action, the object class, and the allowed types with zero waste. Appropriate for a straightforward creation 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 and the schema fully documents the 8 parameters, so return values and argument meaning are covered elsewhere. However, for a mutation tool with no annotations and a session_key parameter implying multi-session targeting, the description omits any session/scene context, leaving a modest gap.

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

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

Schema description coverage is 100%, so every parameter (name, size, scale, parent, position, rotation, session_key) is already documented in the schema; the description only echoes the type enum. Baseline 3 is appropriate since the description adds essentially nothing beyond structured fields.

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 a polygon primitive") and enumerates the supported kinds, so the agent immediately knows what the tool produces. It does not explicitly distinguish itself from siblings like duplicate_object or the execute_python/execute_mel escape hatches, which keeps it short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives such as duplicate_object or constructing geometry via execute_python/execute_mel. No prerequisites, session requirements, or exclusions are stated.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It signals a destructive action via 'Delete' but omits critical details: irreversibility, confirmation requirements, session targeting implications, or side effects on related nodes.

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 a single, front-loaded sentence with no wasted words. It is appropriately sized for a terse statement, though its brevity contributes to gaps in other dimensions.

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 operation with no annotations and no usage guidance, the description is incomplete. Output schema exists and handles return values, but the description fails to address safety, reversibility, or session context that an agent needs before invoking a delete tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the pattern matching capability already documented in the schema and adds no new syntax, format, or edge-case guidance for either 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?

Description states a specific verb ('Delete') and resource ('nodes') with the matching mechanism ('by name or wildcard pattern'). It clearly conveys what the tool does, though it does not differentiate from siblings (none of which are deletion tools).

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 on when to use this tool versus alternatives, no prerequisites, and no conditions or exclusions. The description simply states the action without any contextual routing.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Duplicate a node' implies a write/mutation but says nothing about whether the copy is deep or shallow, how name collisions are resolved, required permissions, or whether the original is affected. These are meaningful gaps for a mutation tool.

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

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

A single front-loaded sentence that names the core action first and the optional modifiers after. No wasted words.

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

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

An output schema exists, so return values need not be explained, and the schema covers all parameters. However, for an unannotated mutation tool the description omits copy semantics (deep vs shallow, collision behavior), leaving the agent with only minimum-viable context.

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 (node, name, parent, session_key) are already documented in the schema. The description reinforces the name/parent options but adds no syntax or behavioral detail beyond the schema, 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 ('Duplicate a node') and clarifies that the copy can optionally be renamed and reparented, which distinguishes it from the standalone rename_object and parent_object siblings. It does not explicitly name those siblings, 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?

The word 'optionally' implies combined rename/reparent behavior, but there is no explicit when-to-use guidance or routing to alternatives like rename_object, parent_object, or create_primitive. The agent must infer that this is the one-shot copy operation.

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?

No annotations are provided, so the description carries the full behavioral burden. For arbitrary code execution, it says nothing about sandboxing, permission requirements, error behavior on failure, or the risk of running unchecked commands; 'escape hatch' gestures at risk but discloses no actual behavior. The undo-chunking and timeout details live only in the schema, not the description.

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 ten-word sentence that is front-loaded with the verb and resource and contains no filler. It is arguably too terse for an execution tool, but every word earns its place and nothing is padded.

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

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

An output schema exists, so return values need not be described, and the schema fully covers parameters. What is missing is behavioral context for a powerful execution tool with zero annotations: safety posture, failure modes, and session targeting expectations are left entirely to inference.

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 each of the four parameters (cmd, undo, timeout_s, session_key) already documented in the schema including defaults and ranges. The description adds no parameter-level meaning 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 and resource: 'Evaluate a MEL command inside Maya', which is unambiguous and tells the agent this executes MEL rather than Python. The parenthetical 'escape hatch' hints at its role versus the dedicated sibling tools, but it never names execute_python or any alternative explicitly, so sibling differentiation is only implied.

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 'escape hatch' implies this is a fallback for tasks no dedicated tool covers, which is useful implied guidance. However, there is no explicit statement of when to prefer it over execute_python, nor any exclusion or precondition for its use.

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

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

With no annotations at all, the description carries the full burden and does meaningful work: it explicitly warns there is no security sandbox, that files and system commands are reachable, and that destructive patterns are gated behind allow_dangerous=True. It does not cover the default undo wrapping or timeout behavior, but the safety profile is unusually well disclosed.

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, zero filler, and the critical safety warning is front-loaded immediately after the one-line purpose. Nothing here could be cut without losing necessary information.

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

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

An output schema exists, so return-value explanation is unnecessary, and the schema covers session/namespace/timeout mechanics. The remaining gap is the absence of any statement about when this tool should be chosen over its typed siblings, but for a dangerous escape-hatch tool the safety disclosure is 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 coverage is 100%, so all seven parameters are already documented, including code, undo, timeout_s, persistent, namespace_key, and allow_dangerous. The description only reinforces the meaning of allow_dangerous; the 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 and resource (run arbitrary Python inside Maya) and labels itself an 'escape hatch', which implicitly separates it from the typed siblings like rename_object, set_attributes, or execute_mel. An agent can immediately tell this is the fallback for operations no dedicated tool covers.

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 'escape hatch' framing implies this is the last resort rather than the first choice, but it never says when to prefer it over execute_mel or the typed tools, nor when not to reach for it. Usage is implied rather than stated.

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

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

No annotations are provided, so the description must carry the behavioral load. It implies a read-only operation via 'Read', but does not disclose session targeting, error behavior, idempotency, or any other traits an agent would need to invoke it confidently.

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 a single, front-loaded sentence with no wasted words. While it is extremely terse, it is appropriately concise for a tool whose parameters and return values are covered by the schema and output 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?

The output schema exists and the input schema has full coverage, reducing the burden on the description. However, the description still lacks usage guidance and sibling differentiation, leaving an agent without enough context to choose this tool confidently over alternatives like set_attributes or get_scene_info.

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

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

Schema description coverage is 100%, so the input schema already fully documents all three parameters. The description adds no parameter-level meaning beyond what the schema provides, making the baseline score of 3 appropriate.

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

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

The description 'Read attributes of a node' states a specific verb (read) and resource (attributes of a node), making the basic action clear. However, it does not differentiate from sibling tools like set_attributes or get_scene_info, leaving the agent to infer when this tool is the right choice.

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 provides no when-to-use guidance, no conditions for selecting this tool over alternatives, and no mention of prerequisites or related tools. It is a bare statement of function with no routing 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read via 'Summarize'/'Get' but never states that it is non-mutating, that it requires an active Maya session, or how session targeting (session_key) behaves or fails.

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 zero filler; the verb and resource come first and the reported fields follow. Every token earns its place.

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

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

With a 100%-covered single optional parameter and an existing output schema, the description covers the essentials for a simple read tool. It could still mention session targeting or open-scene requirements, but nothing critical is missing.

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

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

There is one parameter at 100% schema description coverage, so the schema already documents session_key ('Target Maya session.'). The description adds no session-selection semantics, 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 gives a specific verb ('Summarize') and resource ('the current scene') and enumerates the fields it reports, so an agent knows exactly what comes back. It does not explicitly differentiate itself from adjacent readers like list_objects or get_attributes, 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?

Usage is implied: call this when you need a scene-level overview rather than per-object data. However, no alternative is named and no when-not conditions or prerequisites (e.g., needing an open scene) are stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a safe read, but nothing states whether it targets the active session by default, what happens when multiple sessions exist to choose from, or whether it mutates anything. For a session-scoped tool with zero annotation coverage this is thin.

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 zero filler. Nothing extra to trim.

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

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

An output schema exists, so return values need not be explained, and all parameters are documented in the schema. However, with no annotations the description should say more about session targeting and any failure mode (e.g., empty selection, no active session) for an agent to call this confidently across sessions.

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 session_key and include_shapes are already documented in the schema, including the default-true behavior of include_shapes. The description adds nothing about parameters, 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?

Clear verb 'List' plus a specific resource, 'currently selected nodes'. It is distinguishable from the setter sibling select_objects and from list_objects, but the description never names or contrasts those siblings, so the distinction is inferred rather than stated.

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

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

There is no guidance on when to use this versus select_objects (the mutation counterpart) or list_objects (scene inventory). The agent must infer the read-vs-write split entirely from the tool names.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it omits that this is a read-only operation, says nothing about pagination or result-size limits, and does not explain how the optional session_key affects targeting. It only restates the filtering behavior already visible 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?

A single tight sentence with the resource front-loaded and the optional filtering trailing. No filler or redundancy, though it is arguably too terse for a tool with three parameters and no annotations.

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 parameters are fully documented in the schema. The remaining gap is routing: with 20 siblings, the description never explains when this listing tool is the right choice over get_selection or get_scene_info.

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

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

Schema description coverage is 100%, so the schema already documents pattern (wildcard on names), session_key, and type_filter with its enum values. The description echoes the type/name filters but adds no syntax, wildcard-format, or default-behavior detail beyond the schema, 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?

Clear verb+resource: 'List scene nodes' states exactly what is returned, and it names the two filtering dimensions. It does not, however, distinguish itself from siblings like get_selection or get_scene_info that also enumerate scene entities, so an agent must infer the boundary.

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

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

The description says the filters are optional but never states when to reach for this tool versus get_selection, get_scene_info, or select_objects. There is no context, prerequisite, or exclusion guidance — only a restatement of the parameter behavior.

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?

No annotations are provided, so the description carries the full burden. It discloses the shape of the returned records, which is useful, but says nothing about read-only nature, latency, or whether the list can be empty or stale. Adequate but thin for an unannotated tool.

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

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

A single front-loaded sentence with zero filler; the resource and its payload are stated immediately. Nothing redundant or padded.

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

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

With an output schema present, the description need not explain return values, yet it briefly names the key fields, which aids fast selection. Combined with zero parameters and a simple read operation, it is essentially complete for the agent's needs.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The listed output fields add minor value but do not substitute for parameter documentation that is not needed.

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

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

States a specific verb and resource (list connected Maya instances) and enumerates the returned fields (session_key, versions, scene, tools, active), so the agent knows exactly what it produces. It does not explicitly differentiate itself from siblings like maya_ping or set_active_instance, but the name and scope are still unambiguous.

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

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

Usage is implied rather than stated: this is clearly a discovery call whose session_key output feeds other tools, but the description never says "call this first" or names an alternative. No when-not guidance is given, so the agent must infer 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?

With no annotations, the description carries the full burden and does disclose a genuinely non-obvious trait: non-core groups start disabled to keep the tool list small. It does not explain the side effects of 'disable' (e.g. whether in-flight or persisted state is affected), leaving a modest gap.

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

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

Two sentences, front-loaded with the core capability, followed by the non-obvious default-state caveat. Every clause earns its place with zero 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?

An output schema exists, so return values need not be described. The description covers the key default-disabled behavior and how to reveal groups, which is sufficient for this low-complexity meta-tool; only the exact effect of 'disable' is 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 coverage is 100% with all three parameters (action, group, tool) fully documented and an enum on 'action'. The description's example reinforces the action/group pairing but adds no syntax beyond what the schema already 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 pair ('list or toggle') and resource ('tool groups'), which is clearly distinct from the Maya operation siblings. It does not explicitly name a sibling to disambiguate against, but the meta-resource makes the scope unambiguous.

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

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

Explains when this matters — non-core groups (authoring/animation/rendering) are disabled by default — and gives a concrete enabling call ('action=enable, group=authoring'). It lacks explicit when-not/exclusion guidance, but the trigger condition is clear.

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?

No annotations exist, so the description carries the full burden, and it does convey that this is a pre-flight connectivity check rather than a mutating action. However it says nothing about failure modes (timeout, no instance connected) or whether the call has side effects on the plugin link, which would matter for a diagnostic gate.

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, zero padding, and the action is front-loaded ahead of the usage hint. Nothing here is wasted.

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

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

An output schema exists, so return-value detail is unnecessary, and the single optional parameter is fully covered by the schema. The only gap is undisclosed behavior on a failed ping, which is minor for a read-only diagnostic.

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

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

Schema coverage is 100% and the single optional session_key is already documented as 'Target Maya session; omit if only one is connected.' The description adds nothing about session targeting, which is acceptable given the schema does the work, but it is not adding value.

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

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

The description names a specific verb and resource ('Check connectivity to a Maya instance') and adds the payload ('return basic instance info'), so the agent knows exactly what this does. It does not explicitly distinguish itself from near-neighbours like list_sessions or get_scene_info, which an agent might reasonably reach for instead.

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 condition for use: 'verify the server/plugin link before running other tools.' That is genuine when-to-use guidance, but there is no when-not and no named alternative to compare against, so the routing is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that omitting the parent unparents to the world, but it does not mention side effects such as whether world/local transforms are preserved, whether the child must already exist, or error behavior for an invalid parent.

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 covering both directions of the operation with zero filler. Every clause earns its place.

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

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

An output schema exists, so return values need not be explained, and all parameters are documented. However, as a scene-mutating hierarchy tool with no annotations, it should say more about transform preservation and preconditions to be fully 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%, so the schema already documents 'child', 'parent', and 'session_key' including the omit-to-unparent semantics. The description adds no meaning 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?

The description states a specific verb (parent/unparent) acting on a resource (a node), and the dual operation is explicit. It is clearly distinguishable from siblings like duplicate_object or delete_objects, though it does not name or contrast any specific alternative.

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

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

Usage is implied by the operation itself: use it to change hierarchy. There is no explicit statement of when to prefer this over alternatives, no prerequisite conditions, and no exclusions, so guidance is only implicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that this is a mutation, whether renaming affects references or expressions, what permissions are needed, or how failures are reported. For a mutation tool with zero annotation coverage, this is a critical gap.

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

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

The description is a single clear sentence with no wasted words. However, it is so terse that it omits necessary structure and context for a mutation tool, bordering on under-specification rather than purposeful conciseness.

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?

While an output schema exists and the input schema is fully documented, the description fails to address when to use this tool, the behavioral implications of renaming, or the optional session_key parameter's effect. With no annotations, the description leaves important operational context 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 defines the node, new_name, and session_key parameters. The description adds no meaning beyond the schema, which is the baseline 3 when structured fields do 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 'Rename' and resource 'node', so the core action is clear. However, it offers no differentiation from sibling tools such as parent_object, duplicate_object, or delete_objects, which also manipulate scene nodes.

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

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

There is no guidance on when to use rename_object versus alternatives, no prerequisites, and no mention of whether the node must exist or be selected first. The description simply states the action without any usage context.

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

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

With no annotations provided, the description carries the full disclosure burden, yet it says nothing about what happens to the current scene or its unsaved changes. The fact that creating a new scene can destroy in-progress work is only hinted at indirectly by the schema's 'force' parameter, not by the description. That is a material omission for a state-replacing operation.

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 zero filler. It states the action and result immediately with no 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?

An output schema exists, so return values need not be explained. However, for a tool that replaces the current scene, the description omits the behavioral context an agent needs: whether unsaved work is discarded or prompted, and whether a session must be active. The description is too thin for the destructive potential of this operation.

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 'force' and 'session_key' are already documented in the schema and the baseline is 3. The description adds no parameter meaning beyond that, contributing nothing extra.

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 new, empty scene'), which cleanly separates it from siblings like scene_open and scene_save. It doesn't explicitly name a sibling or state the distinguishing condition, but the operation is unambiguous.

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

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

There is no guidance on when to use this rather than scene_open, or on prerequisites such as needing an active Maya session. Usage is only inferable from the verb 'Create', with no conditions or exclusions 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?

With no annotations, the description carries the full behavioral burden, and it does little: it does not say that opening replaces the current scene and can discard unsaved work, that force suppresses that prompt, or that a live Maya session is required. 'Open (or reference)' adds no safety or side-effect context.

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

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

A single front-loaded sentence with no filler. It is efficient, though its brevity is partly under-specification rather than pure concision.

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, but for a mutating file-open with zero annotations the description is too thin: session prerequisites, unsaved-change behavior, and the open-vs-reference distinction are left entirely to the schema.

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

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

Schema coverage is 100%, so path, force, reference, and session_key are all documented in the schema itself. The description contributes nothing beyond the schema, which is the baseline 3 for full-coverage schemas.

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 (Open) and resource (Maya scene file), and the parenthetical '(or reference)' hints at the dual mode covered by the reference flag. It does not explicitly distinguish itself from siblings like scene_new or scene_save, but the intent is unmistakable.

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 on when to open versus reference, when to set force, or how session_key selects a target. The agent must infer all of this from the schema alone. No alternatives or preconditions are 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?

No annotations exist, so the description carries the full burden, and it discloses almost nothing: it does not say the scene is written to disk, that an existing file may be overwritten, that a prompt may appear, or that session_key targets a specific Maya instance. Everything of that nature lives in the schema fields, not the description.

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 repetition, which is appropriate for a simple three-parameter tool. It is arguably too terse rather than too long, but 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?

An output schema exists, so return values need not be explained, and parameters are fully documented in the schema. However, for a mutation tool with no annotations, the description omits any mention of the write/overwrite side effects, leaving a real gap relative to its complexity.

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

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

Schema description coverage is 100%, so the schema already documents path, force, and session_key with more detail than the description provides. The description's 'optionally to a new path' merely restates the path parameter, so it adds no meaning beyond the schema; 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 (Save) and resource (the current scene), and the parenthetical clarifies the save-as variant. It is clearly distinguishable from siblings like scene_new and scene_open by verb alone, though it never names an alternative.

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

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

There is no guidance on when to use this versus scene_new/scene_open, no preconditions (e.g. an active session or unsaved changes), and no note about prompting. The parenthetical hints at a save-as case but gives no decision criteria.

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

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

With no annotations, the description carries the full behavioral burden, and it mostly fails to: it doesn't state that the tool mutates the scene's selection state, what happens to a prior selection by default, or what occurs when a pattern matches nothing. The 'extend' semantics live only in the parameter schema, not the description.

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 but arguably too terse for a selection-mutating tool, so it stops short of 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?

An output schema exists, so return values need no explanation, and the parameters are fully covered. The remaining gap is behavioral: for a tool that changes selection state without any annotations, the description should say that it replaces the current selection by default and how pattern matching behaves.

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 three parameters (patterns, extend, session_key) are already documented in the schema, including the replace-vs-extend distinction. The description's 'name or wildcard pattern' phrasing adds no detail beyond the schema, 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 gives a specific verb (select) and resource (nodes) plus the matching mechanism (name or wildcard pattern), which is enough to know what the tool does. It does not, however, differentiate itself from nearby siblings like get_selection or list_objects, so a reader must infer the distinction.

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

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

There is no when-to-use guidance: the description never states that this changes the active selection, nor how it relates to get_selection (read the current selection) or list_objects. The agent must guess which of the selection-related siblings applies.

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

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

With no annotations, the description carries the full disclosure burden. It does reveal one non-obvious behavioral trait: the setting only affects calls that omit session_key, implying explicit session_key usage overrides it. It omits whether the selection persists across reconnects, is scoped per client or globally, or what happens if the chosen instance disconnects.

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 core effect before the situational hint. There is no filler, hedging, 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?

An output schema exists and the sole parameter is fully documented, so return values need no explanation. For a simple default-target selector the description is nearly sufficient, with only the persistence/scope of the setting 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% and the single parameter already documents that instance_id is a 'session_key from list_sessions'. The description adds only the routing implication of omitting session_key, not further format or validation detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('Choose which connected Maya instance handles calls that omit session_key'), which precisely describes the state change and its effect on subsequent routing. It is clearly distinguishable from list_sessions, which supplies the instance_id, and from execution tools like execute_python.

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 condition for use: 'Useful when several Maya instances are open.' Combined with the parameter's reference to list_sessions, an agent can infer the workflow (list_sessions -> set_active_instance). However, it does not state when NOT to use it, nor that it is unnecessary for single-instance setups or for calls that pass session_key explicitly.

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?

No annotations are provided, so the description carries the full burden. It does not disclose whether this requires specific permissions, what happens to existing attributes, whether changes are reversible, or error behavior. The only behavioral hint is that it mutates a node's attributes.

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, efficient sentence with no waste. It is front-loaded and appropriately sized for the action, though it could benefit from slightly more detail.

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

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

For a mutation tool with no annotations, the description is too sparse. It lacks information about side effects, session handling, or error cases. However, the presence of an output schema means return values need not be explained.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no extra meaning beyond what the schema provides, 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?

States a specific verb (Set) and resource (attributes on a node), which is clear and distinguishable from get_attributes. However, it does not differentiate from rename_object or other mutation siblings, and 'one or more attributes' is slightly vague about scope.

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

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

No guidance on when to use this tool versus alternatives like execute_python or execute_mel for attribute manipulation. No prerequisites or exclusions are mentioned.

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

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

With no annotations, the description carries the full burden. 'Display ... to yourself' implies a non-mutating read operation and the modeling workflow hints at how it fits in, but it does not disclose session requirements, behavior on missing/unsupported files, or anything about the second parameter's effect. Adequate but not rich.

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

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

Two short sentences, front-loaded with the core action and followed by the usage condition and workflow. No filler and nothing redundant with 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?

For a two-parameter, no-output-schema tool with full schema coverage, the description supplies purpose, trigger, and follow-up workflow, which is enough to invoke it correctly. Only minor gaps remain, such as session targeting behavior, which the schema already covers.

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 path and session_key are already documented including accepted file formats and the single-session default. The description adds no syntax, format, or constraint information 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 and resource ('Display a local image file') plus the unusual detail that the image is shown to the agent itself, which is a meaningful distinction from sibling capture_viewport. It also names the follow-on tool import_reference_image, so an agent can place it precisely in the workflow.

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 gives the trigger condition ('when the user points you at a reference image') and the sequencing ('view it first, then model'), including the optional alternative path via import_reference_image. It stops short of stating when not to use it or any prerequisites (e.g. needing an active session), but the context is clear.

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