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

With no annotations provided, the description carries full burden. It discloses model trust gates (only Opus/Fable write directly, others stage) and that patterns are available in future sessions. However, it does not mention any destructive effects or authentication requirements.

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

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

Three sentences, front-loaded with purpose, then usage guidelines, then trust gates. No wasted words; each sentence adds essential 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?

Given the tool saves to a knowledge base and an output schema exists (though not shown in input), the description covers purpose, usage, and trust model. It could mention what happens after staging or if patterns can be overwritten, but overall sufficient for an AI agent.

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 input schema already provides clear descriptions for each parameter (api, code, description), so the tool description does not need to add parameter details. The description adds contextual usage info but no new parameter semantics.

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

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

The description clearly states the tool saves a validated working pattern to the RAG knowledge base. It uses specific verbs ('Save', 'call') and identifies the resource, distinguishing it from sibling tools like search_maya_docs or Maya operation 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?

Provides explicit when to use: after successful operation when search_maya_docs returned low relevance (< 60%). Also specifies alternatives (search_maya_docs) and trust gates for different model tiers, giving clear context for invocation.

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 description discloses the primary actions (create material, assign to object) but omits behavioral details such as whether existing materials are overwritten, if new nodes are always created, or any side effects. No annotations are present to supplement.

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, effectively conveying the tool's core function.

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

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

Given the schema's rich parameter descriptions and the presence of an output schema, the description covers the essential purpose and actions. However, it could briefly mention behavior for name generation or handling duplicates.

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 input schema already provides detailed descriptions for all parameters (e.g., color range, material type list). The description adds minimal extra meaning beyond restating the available types and color attribute.

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 clearly states the tool creates a material (listing four specific types) with RGB color and assigns it to an object, distinguishing it from sibling tools like maya_create_light or maya_create_primitive.

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 explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for material creation and assignment but lacks differentiation 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?

No annotations are provided, so the description carries the full burden. It only states 'create a camera', which implies a mutating operation, but does not disclose side effects (e.g., new node added to scene, selection changes, or what happens to existing cameras). For a creation tool, this is insufficient.

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

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

A single, well-structured sentence that is front-loaded with the action and key configurable attributes. No extraneous information, earning 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 the tool has an output schema, the description need not explain return values. It adequately conveys the basic operation but lacks completeness in terms of behavioral context and parameter details. It is minimally adequate.

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

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

The description mentions three of four parameters (position, look-at, focal length) but adds no detailed meaning beyond the schema's own descriptions. The name parameter is omitted. With schema description coverage reported as 0%, the description does not compensate by providing additional context.

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 clearly states the action 'create a camera' and specifies configurable attributes (position, look-at, focal length). This distinguishes it from sibling tools like maya_create_light or maya_create_primitive. However, it could explicitly state that it creates a camera node in the Maya scene.

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

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

No guidance is provided on when to use this tool versus alternatives, such as maya_import_file or maya_create_primitive. There is no mention of prerequisites like an open Maya scene or any context about when this tool is appropriate.

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 available, the description carries full burden for behavioral disclosure. It only states 'create' without specifying side effects, required permissions, or whether the operation is reversible. This is insufficient 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?

The description is a single efficient sentence that front-loads the core purpose. However, it could be slightly more structured by listing the configurable attributes more explicitly.

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 tool has an output schema (not shown) which may document return values, so the description need not explain them. However, it omits mention of position and name parameters, which are configurable. Overall adequate but not complete.

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

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

Schema description coverage is 0% (the tool description does not detail any parameter). Although the schema includes descriptions for each parameter, the tool description only generically mentions 'intensity and color' without adding meaning. It misses position and name, and does not compensate for the low coverage.

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

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

The description clearly states the action (create), the resource (a light in Maya), and specifies the supported light types (directional, point, spot, area, ambient). This distinguishes it from sibling tools like maya_create_camera or maya_create_primitive.

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

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

No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The agent lacks context to choose correctly among creation 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?

Without annotations, description carries full burden but only states basic action. Does not disclose side effects (e.g., naming conflicts, undo behavior), or behavior when position/scale/rotation are omitted.

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?

Single sentence with verb and object front-loaded. Concise, but could include a brief usage note (e.g., naming defaults).

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 (not shown), so return value explanation unnecessary. Lacks guidance on integration with other tools or error handling, but sufficient for basic use.

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?

Input schema has descriptions for each parameter (0% coverage context likely refers to top-level, not nested). Description adds no extra meaning beyond summarizing optional parameters. Baseline 3 as schema already provides meaning.

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

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

Description clearly states verb 'Create', resource '3D primitive', and lists all supported types (cube, sphere, etc.). This distinguishes it from sibling tools like maya_create_camera and maya_create_light.

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 (e.g., maya_mesh_operation for modifications). No mention of prerequisites or 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 full burden. It details fallback behavior for GLB/GLTF, special handling for BVH (pure-Python parser, HumanIK retarget), and explains namespace/scale_factor forwarding. It doesn't cover error conditions or undo behavior, but it provides substantial behavioral context.

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

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

The description is front-loaded with the main purpose and options, then dives into technical details for specific formats. It is relatively concise given the complexity, though some redundancy exists (e.g., repeated mention of namespace/scale_factor in BVH section). Structure is clear.

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

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

Given the tool's complexity (multiple file types with special import logic), the description covers key behaviors. It mentions output implicitly (e.g., BVH leads to HumanIK retarget) but does not discuss return values; however, an output schema exists. It could mention error handling or prerequisites, but overall it is sufficient.

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

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

The description mentions namespace, parent group, and scale factor, adding some context (e.g., group_under created if not exists, BVH skeleton under bvh_grp). However, it does not thoroughly describe each parameter beyond what the input schema provides. The schema itself includes descriptions, so no major gaps.

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 clearly states 'Import 3D files into Maya' and lists supported formats (OBJ, FBX, GLB/GLTF, Alembic ABC, Maya MA/MB, BVH mocap). This distinctively identifies the tool's action and resource, setting it apart from sibling tools like maya_create_primitive or maya_assign_material.

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

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

The description implies when to use the tool (to import external 3D files) but does not explicitly state when not to use it or compare it to alternatives. It provides context for specific formats but lacks general usage 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?

No annotations provided, so description must disclose behavioral traits. It does not mention whether operations modify the original object, create new ones, require selection, or have undo capabilities. For a mutating tool with multiple operations, this omission is critical.

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?

Single sentence with no filler. Front-loaded with 'Execute mesh operations' and lists operations efficiently. Could include more context without sacrificing 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?

For a tool with multiple operation types (some requiring multiple objects), the description lacks behavioral context such as side effects, required object states, or parameter dependencies. Despite an output schema existing, the minimal description is insufficient for complex use cases.

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 input schema provides detailed descriptions for each parameter (e.g., faces, offset, divisions). The description adds a high-level list of operations but does not explain parameter relationships or usage beyond the schema. Schema coverage is high, 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?

The description clearly states the tool executes mesh operations and lists specific types (extrude, bevel, boolean, etc.). It distinguishes from sibling tools like maya_create_primitive (creation) and maya_transform (transformations), but does not explicitly name the resource (e.g., 'on a mesh object').

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. Does not specify prerequisites (e.g., object must exist) or provide when-not-to-use scenarios. Sibling tools like maya_create_primitive are for creation, but no explicit comparison.

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 it well: it discloses that a reference keeps a live link, that replace repoints a node without disturbing its namespace or downstream work, that unload is the reversible counterpart of load, and that destructive removal is excluded for safety reasons.

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

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

Four short paragraphs, each front-loaded with its point: the lifecycle summary, the import-file contrast, the version-swap behavior, and the load/unload/removal boundary. No sentence is 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 multi-operation tool with an output schema already covering return values and no annotations to lean on, the description covers the operation set, the safety boundary, and the sibling relationship. 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?

Top-level schema coverage is 0% and the description compensates by tying parameters to operations, e.g. reference_node is 'the reference_node the other operations require' and is obtained from operation='list', and file_path serves both create and replace. It does not state required-vs-optional per operation or the namespace default, which the nested schema does supply.

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

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

States the verb and resource ('Reference a file into the Maya scene') and enumerates the full lifecycle it manages (create, list, replace, load, unload). It explicitly contrasts itself with the sibling maya_import_file ('copies content in and breaks that link'), so an agent can pick 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?

Gives an explicit when-to-use rule ('prefer this tool whenever the content has its own publish and may be re-versioned') plus the when-not case via maya_import_file, and states that outright removal is deliberately not offered here and requires explicit user confirmation elsewhere.

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 does so: it discloses long-running semantics, default and max timeouts (default 10, max 600), progress heartbeats every 10s, the out-of-process render design that prevents main-thread hangs, the fact that rendering alone does not create a review Version, and the write/destructive nature of new_scene (discards unsaved work only with confirm:true) and delete.

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 preamble is front-loaded and each action is a single scannable bullet with params inlined, which is the right structure for a 13-way dispatcher. It is long, and render_still in particular carries several explanatory clauses ('the review view transform actually applies…'), but almost all of the length is functional 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?

For a 13-action dispatch tool with a 0%-covered schema and an output schema present, this is complete: action semantics, param shapes, timeouts, prerequisites, and side effects are all given, and it even sketches return payloads where they affect follow-up work. Nothing an agent needs to invoke an action 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 0% — params is an untyped free-form object whose only guidance is '(see tool description)' — so the description must define every parameter, and it does: required vs optional params per action, wildcard support for delete/list_scene name filters, and the {label, command} shape for shelf_button. This fully compensates for the schema gap.

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

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

States a specific verb+resource ('Manage Maya session, query scene state, run utility commands') and then enumerates all 13 dispatchable actions with their concrete effects. It explicitly distinguishes itself from siblings, e.g. render_still notes it is 'NOT the VP2.0 grab of maya_viewport_capture', so an agent can route correctly without reading 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?

Every action carries when-to-use context: new_scene 'Refuses if the current scene has unsaved changes', operation_history 'needs MAYA_AUDIT_LOG=1', render_still points to maya_viewport_capture for fast screenshots, and review_turntable/render_still both mandate resolving out_path via the fpt tk_resolve_path template. It stops short of stating when the overall dispatch tool should be preferred over single-purpose siblings like maya_transform.

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 full burden but only states the action. It omits behavior like whether existing keyframes are overwritten, animation curve effects, or prerequisites (e.g., object must exist).

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

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

The description is a single, focused sentence. It is front-loaded and efficient, with no redundant 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?

Adequate for a simple keyframe tool but incomplete: does not mention return value (output schema exists), error handling, or interpolation behavior. Could add context on attribute default or tangents.

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

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

Schema description coverage is 0% per context, but the schema's property descriptions exist. The tool description does not add meaning beyond listing parameters; it does not explain relationships or usage order.

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 is specific: 'Create an animation keyframe on an object' and lists animatable properties (translate, rotate, scale, visibility), clearly distinguishing it from siblings like maya_transform.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., maya_transform for non-keyframe transformations). The description provides no when-not or context-of-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?

No annotations provided, so description should disclose behavioral traits. It does not mention whether transforms are absolute or relative (though 'relative' parameter exists), or any side effects like history changes. Only states the action types.

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?

Single sentence, no wasted words, but overly sparse. Could include more context without losing 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?

Despite output schema existing, the description fails to cover the tool's complexity (3 operations, 5 parameters). No mention of parameters or how to use them, making it incomplete for a transform 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 descriptions cover parameters fully (e.g., 'New scale [x, y, z]'), so baseline is 3. The tool description adds no additional meaning beyond what the schema provides.

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

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

Description uses specific verbs (move, rotate, scale) and identifies the resource (object in Maya scene), clearly distinguishing from sibling tools like maya_create_primitive or maya_assign_material.

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 vs alternatives, nor any conditions for move vs rotate vs scale. No exclusions or prerequisites 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 behavioral burden and largely succeeds: it discloses the <1s latency, that it never touches the user's focused viewport, that it spins up a throw-away modelPanel forced to vp2Renderer, and the failure mode it avoids (Arnold IPR saturation hanging Maya's main thread). It omits return-shape and side-effect details (e.g. whether output_path is written or only returned), which keeps it short of 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 with the core action and its alternative before any mechanism detail, and the NEVER clause is a deliberate safety disclosure rather than filler. The parenthetical about rendererName='vp2Renderer' and the memory-feedback ID are more verbose than an agent strictly needs, but they justify their length.

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

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

No output schema and no annotations, so the description must stand alone, and it covers purpose, alternative, timing, safety behavior, and use cases well enough to call the tool correctly. What it leaves unstated is how the image is returned (inline vs path-only) and whether output_path is always written, which are minor against an otherwise thorough definition.

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

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

The description adds no meaning for any of the five underlying parameters (frame, width, height, camera, output_path); a reader would not learn from it that a camera or frame can be selected. Reported schema description coverage is 0%, so the description is expected to compensate and does not, though the nested ViewportCaptureInput properties do carry brief descriptions of their own.

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 Maya viewport as PNG/JPG image') and immediately scopes it against the nearest sibling, clarifying it is an instant Viewport 2.0 grab rather than an Arnold render. An agent can distinguish it from maya_session(action='render_still') 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?

Explicitly names the alternative and the selecting condition ('for a ray-traced still use maya_session(action='render_still')'), and lists concrete use cases (verifying scene state, lighting, framing). The when-not is stated as strongly as the when.

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?

Discloses key traits: GPU requirement, no persistence (URL only in memory), non-blocking jobs. Missing details on error handling, whether it modifies the Maya scene, or output cleanup, but still highly informative.

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-structured with bullet points for each action and a clear workflow. Slightly verbose (multiple paragraphs) but earns its length by covering all necessary details.

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

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

Covers the entire pipeline from server selection to download, including async behavior. No gaps in understanding how to use this complex 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?

Despite 0% schema coverage (schema only defines dispatch structure), the description fully documents each action's parameters with examples (e.g., 'Required params: {"image_path": ...}'). Compensates completely for lack of schema detail.

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

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

The description clearly identifies it as 'AI-powered 3D asset generation via Vision3D server' and lists all sub-actions (select_server, health, generate_image, etc.). Distinct from sibling Maya tools (e.g., maya_create_primitive) which focus on direct scene manipulation.

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 workflow: first select_server (ask user for URL), then start generation, poll, download. States 'jobs are non-blocking: start → poll → download' and provides required/optional params for each action.

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?

Without annotations, the description takes full burden and discloses key behaviors: credit spending only with confirm=true, resumability via sidecar, that build runs in Maya, and draw_mode options. It could be improved by mentioning whether operations are destructive or reversible, but overall it is transparent.

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 comprehensive but verbose, containing several paragraphs and very detailed parameter lists. It is front-loaded with the purpose, but the length could be trimmed without losing essential information, making it less efficient for quick parsing.

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 dispatch tool with 7 actions and no annotations, the description is mostly complete for inputs but lacks details on outputs per action (e.g., poll returns). The presence of an output schema (not shown) may mitigate this, but the description does not reference it, leaving a gap for agents.

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 input schema is generic (only action and params as any), providing 0% coverage. The description fully compensates by listing all parameters for each action with types, examples, and optional flags, adding essential meaning beyond the schema.

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

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

The description clearly states the tool's purpose: generating a World Labs Gaussian-splat environment from an image and loading it into Maya for Arnold. It distinguishes the tool from siblings by its specific pipeline of actions, and the name itself signals the domain.

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 a clear pipeline order (generate → poll → download → convert → build) and gives explicit guidance on credit spending and resuming interrupted runs via status. However, it does not compare directly to sibling tools or state when not to use it, though the specialized nature makes alternatives obvious.

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 provided, so description carries full burden. It discloses immediate zeroing, reset of counters, and return of confirmation timestamp. Missing explicit statement that it is destructive (clears data irreversibly), but 'Zero' sufficiently implies mutation.

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

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

Three precise sentences front-loaded with the action. Every sentence earns its place: action, usage context, return value. 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?

Given zero parameters and output schema existence, description fully captures behavior: immediate reset, use case, and return value. Complements schema and context signals.

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?

No parameters; baseline 4 applies. Description adds no parameter info, but none is needed as the schema is empty and coverage is 100%.

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 clearly states the action: 'Zero the session stats counters immediately.' It uses specific verb 'Zero' and resource 'session stats counters', distinguishing it from the sibling 'session_stats' which presumably reads stats.

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

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

Explicitly states when to use: 'at the start of a new Claude session (or a fresh debugging run) when the idle-based auto-reset has not fired'. Provides a concrete example (back-to-back sessions) and contrasts with alternative behavior (auto-reset).

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 present, so the description carries the full burden. It discloses the RAG technique, HyDE query expansion, and that results include relevance scores. It does not discuss side effects or rate limits, but such details are less critical for a search 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?

The description is concise (four sentences), front-loaded with the core purpose, and each sentence adds distinct value (what, when, what covers, how). No fluff 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?

Given the presence of an output schema and rich input schema, the description covers the tool's overall role, supported content, and advanced technique. Minor gaps (e.g., parameter details) are mitigated by the schema, so completeness is high for a search 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 0% because the tool description does not mention parameters. Although the input schema itself provides detailed parameter descriptions, the low coverage means the description must compensate; it fails to do so, leaving the agent without higher-level parameter semantics from the free text.

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 clearly states 'Search Maya API documentation using hybrid RAG (semantic + BM25)' and lists covered domains (maya.cmds, PyMEL, etc.). It distinguishes from sibling tools that perform specific Maya actions by positioning itself as a preliminary research step.

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 usage guidance is provided: 'Call this BEFORE writing complex Maya commands, using unfamiliar flags, or when unsure...' This helps the agent decide when to use it, though it does not explicitly state when not to use it or mention alternatives.

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

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

With no annotations, the description carries full burden, describing output details like RAG savings compared to full documentation, implying a read-only statistics 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?

Three concise sentences with front-loaded purpose, usage guidance, and output detail; 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?

Given zero parameters and presence of output schema, description fully covers when to use and what information is provided, including specific RAG comparison.

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?

No parameters, baseline 4. Description adds context about what statistics are displayed, compensating for lack of param info.

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 clearly states the tool shows session efficiency statistics (token usage, RAG savings, patterns learned), distinguishing it from siblings like reset_session_stats and learn_pattern.

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

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

Explicitly says to call at the end of multi-step tasks or when asked about efficiency, providing clear usage context, though it doesn't specify when not to use.

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