omniverse-mcp

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

Annotations already declare a non-destructive write (readOnlyHint=false, destructiveHint=false); the description adds real behavioral context beyond them: simulation-state prerequisites, the three refusal conditions, and the known #58 gap for articulation links. It doesn't disclose whether the push persists across steps or how failure is surfaced in the response, keeping it off 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?

Three short sentences, ledger-clean: capability first, then state precondition, then refusal cases. Every sentence carries information an agent needs and nothing is repeated from structured fields.

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

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

With an output schema present, full parameter descriptions, and annotations covering the safety profile, the description supplies exactly the missing pieces — preconditions and refusal behavior. An agent has everything needed to call this correctly or recognize when it will be rejected.

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

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

Schema description coverage is 100%, so the schema already explains force vs impulse semantics, units, and the position default. The description adds only the conceptual note that mass is respected, with no guidance on choosing impulse=true or interpreting position, 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 — push a rigid body via PhysX — and adds a scope detail ('so its mass counts') that tells the agent this is a mass-aware dynamics operation, not a transform set. It is clearly distinct from siblings like set_prim_transform or set_physics_properties without opening any schema.

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

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

Gives explicit preconditions ('the simulation must be playing or paused') and explicit exclusion cases (disabled bodies, kinematic bodies, articulation links), which is strong when-to-use guidance. It stops short of naming an alternative tool for the unsupported articulation-link case, leaving the agent to guess a workaround.

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

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

Annotations declare readOnlyHint=true, which is consistent with a capture operation, and the description goes beyond that by disclosing the side effect of writing three files to disk and their contents. It also warns that include_image increases context usage — useful behavior not in the annotations. The save location of the files is not stated, a minor 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?

Front-loaded with the action and result, then a numbered breakdown that is easy to scan. It is longer than strictly necessary but every line conveys a distinct output artifact, so there is little waste.

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

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

Output schema is absent, and the description compensates by fully explaining the three returned files and the inline-image option. The only missing detail is where the files land on disk, which an agent would need to actually consume them.

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 width, height, camera_path, and include_image are each documented in the schema. The description reinforces include_image's trade-off but adds nothing beyond the schema's own text, 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?

Specific verb (capture) plus resource (viewport) with a precise enumeration of the three artifacts produced. An agent immediately knows this tool produces visual + spatial data as opposed to any sibling like dump_scene or get_scene_tree.

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 tells the agent how to combine the outputs ('Use files 2 and 3 to understand which prim is where') and gives a clear condition for include_image=True with its context cost trade-off. It does not name alternative sibling tools for scene inspection, but the usage context is unambiguous.

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

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

Annotations only declare the safety profile (not read-only, not destructive); the description adds real behavioral context by specifying the deep-copy semantics including children and the fail-fast refusal of an occupied target before any copying occurs. It stops short of describing what error is raised or whether partial state can occur mid-batch.

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

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

Three short sentences, front-loaded with the core action and followed by the atomicity guarantee. Every sentence contributes a distinct fact and nothing is repeated from 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 scene-mutating clone tool with a full parameter schema, complete annotations, and an output schema, the description covers purpose, scope (children included), batch support, and the key failure precondition. Only the error/return behavior on refusal is left implicit, which slightly limits completeness.

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 schema already explains count, offset, and both paths with examples, so the schema carries the load. The description's "Supports batch cloning" corroborates the count/offset parameters but adds no format or edge-case detail beyond the schema.

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

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

States a specific verb and resource: "Deep-copy a prim (and all children) to a new path", which immediately tells an agent this duplicates rather than moves or creates-from-scratch. It does not explicitly distinguish itself from the close sibling create_prim, so it falls just short of a 5.

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

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

Provides one important precondition ("Refuses a target path that already holds a prim"), which is genuine usage guidance for choosing a target. However, it never says when to prefer this over create_prim or how it relates to other construction tools, so the when-to-use rationale is only implied.

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

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

Annotations declare readOnlyHint=false, and the description supplies the missing context: it explains it clears BBoxCache between variant switches to avoid stale data, which justifies the non-read-only flag and warns about a correctness pitfall. It also states the return shape (side-by-side stats with deltas). It does not describe cost/rate behavior, so not a 5.

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

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

Front-loaded with the purpose, then a clean numbered mode list, then return/behavior notes. Dense and mostly waste-free; the BBoxCache sentence is an implementation detail but earns its place as a correctness signal.

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

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

With an output schema present, the description needn't detail return values, and it still summarizes them as side-by-side stats with deltas. For a six-param, two-mode tool this is nearly complete; only the reason readOnlyHint is false (full side-effect scope) and default-empty-string handling are unstated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the crucial grouping semantics: which parameters are mutually exclusive per mode and that all six are optional with mode determining which to supply. That is meaning beyond the per-field 'the first'/'the second' docs, though it does not address defaults or empty-string behavior.

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 (compare) plus the exact resources (two prims or two variants) and the dimensions compared (mesh counts, bounds, materials). This clearly separates it from siblings like get_mesh_stats or get_prim_bounds, which inspect a single prim.

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 enumerates two modes and the parameter combinations that select each (prim_path_a/prim_path_b vs prim_path/variant_set/variant_a/variant_b), which is exactly the guidance an agent needs to pick a mode. It stops short of naming when to prefer a sibling tool (e.g. get_mesh_stats for a single prim) or any exclusions.

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

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

Annotations already declare non-readonly, non-destructive, closed-world, so the bar is lower, and the description still adds real value: the existing-prim conflict semantics (type preserved, mismatched type refused) are non-obvious and prevent a failed call. It omits whether the parent path must exist, whether the creation is persisted or requires save_scene, and how partial failures behave.

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

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

Three short sentences, front-loaded with the core action, and no filler. The type enumeration earns its place as a discoverable hint. Minor structural noise from stray indentation and blank lines keeps it from 5.

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

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

With an output schema present, the description needn't explain return values, and annotations cover safety. What remains necessary for correct invocation – available types, the usd_path alternative, and the existing-prim collision rule – is all stated, making this complete for a creation tool.

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

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

Schema coverage is 100%, so the schema already documents scale, position, rotation, usd_path, prim_path, prim_type, and enable_physics thoroughly. The description adds only one semantic not in the schema – that usd_path is an alternate mode that substitutes for prim_type. Baseline 3 is correct when the schema does the heavy lifting.

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

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

The first line gives a specific verb and resource ("Create a new prim in the scene") that an agent can match against clone_prim or create_robot without opening the schema. It then enumerates the concrete prim types, grounding the abstraction. It stops short of 5 because it never explicitly contrasts itself with the nearest sibling (clone_prim) or create_robot.

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 conditions are genuinely stated: choose a prim_type, or alternatively supply usd_path to reference a USD file. The conflict rule ("A prim already at prim_path keeps its type: one of another type is refused") tells the agent the preconditions under which the call will fail. No explicit when-not or named sibling alternative, so not a 5.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the write-vs-read nature is already conveyed. The description adds the prim-naming default when prim_path is empty, which is useful, but omits whether an existing prim is overwritten or whether a stage must be loaded first.

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 definition is short and front-loaded, with the resource type and alternatives stated first. The opening phrasing ('one of Isaac Sim's asset library by name') is slightly awkward, costing it a point on polish.

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 and 100% parameter coverage, the description needn't explain returns. It covers names, path formats, and naming defaults well; the only gap is scene-precondition and overwrite behavior for a mutation tool.

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

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

Schema coverage is 100% and the schema has no enum for robot_type, so the description's enumeration of valid robot names (franka, ur10, carter...) plus the USD path formats (Kit machine path, URL, /Isaac/... path) is real added meaning. The prim_path naming default also clarifies behavior 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 opens with a specific verb and resource: 'Add a robot' distinguished as either an asset-library name or a robot's own USD file. This clearly separates it from the generic create_prim sibling, though it does not explicitly contrast with create_prim by name.

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 tells the agent the two calling modes (library name vs. USD path) and enumerates the available names, giving clear context for selection. It does not state when to prefer create_prim over this tool, so an explicit exclusion is missing.

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

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

Annotations show this is a non-destructive write (readOnlyHint=false, destructiveHint=false), and the description usefully spells out what actually happens: the variant set is added, empty variant bodies are created, and a default is set. It stops short of stating what happens if the set already exists or whether the prim is modified in place.

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 verb and resource, then a single sentence enumerating the three concrete effects. No wasted filler, though the two sentences partially restate the same action.

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

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

An output schema exists, so return values need not be explained, and all four parameters are fully documented in the schema. The description covers the core behavior adequately; only edge-case behavior (e.g. existing set name collisions) is unaddressed.

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

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

Schema coverage is 100%, with each of the four parameters carrying its own description and examples (e.g. variant names, default-variant fallback rule). The description adds virtually no parameter-level 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?

States a specific verb and resource: 'Create variant set boilerplate on a prim,' followed by the concrete effects (adds set, creates empty bodies, sets default). An agent can distinguish this from creation vs. selection, though it never names the closest sibling set_variant_selection to sharpen the boundary.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no mention of prerequisites such as the prim needing to exist. The nearest alternative (set_variant_selection) and the condition separating them is left entirely to inference.

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

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

Annotations already flag destructiveHint=true, so the safety profile is covered; the description's real contribution is the cascade semantics — deleting children too — which is exactly the 'what gets destroyed' context that annotations cannot express. It stops short of stating irreversibility or side effects on references/instances.

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?

One short sentence, front-loaded with the action and the single most important qualifier (child cascade). Nothing redundant.

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 and parameter docs are handled elsewhere, so the description only needs behavioral coverage; it provides the cascade scope but says nothing about failure modes, undo, or effect on instanced/referenced prims — meaningful omissions for a destructive 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 coverage is 100% and the prim_path property already documents the expected format ("Full USD path of the prim, e.g. /World/Robot"). The description adds nothing beyond that, so baseline 3 applies.

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

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

States a specific verb (delete) and resource (prim) and adds scope (and all its children), which distinguishes it from the other mutating siblings like clone_prim or set_visibility. It doesn't explicitly contrast with any alternative delete/undo path, but the intent 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?

No guidance on when to use this versus other cleanup approaches, no preconditions (does the path need to exist? does it fail on a missing prim?), and no note about reversibility. The agent is left to infer everything from the single sentence.

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?

Beyond the annotations, the description discloses critical behavior: drawings are 2 pixels wide, last for duration seconds, use isaacsim.util.debug_draw/omni.debugdraw depending on the app, and expiring a drawing clears all lines drawn through that debug draw, including other code's lines. It also warns that a new stage drops prior drawings.

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: the first sentence states the action and shape options, then it moves to backend and cleanup caveats. Every sentence carries useful information, with no filler.

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

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

Given the rich schema, annotations, and output schema, the description covers the key ambiguities an agent would face: what is drawn, how long it persists, which backend is used, and the cross-code cleanup side effect. Return values need not be described because an output schema exists.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful shape interpretation: line, polyline, sphere as three crossing lines, and points as small crosses. It does not explain every parameter, but it improves understanding of the required shape selector.

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: 'Draw debug lines in the viewport,' and enumerates the exact shapes supported. This clearly distinguishes it from scene, camera, recording, and simulation siblings that do not draw transient debug geometry.

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 'draw debug lines in the viewport,' but the description never states when to choose this over alternatives such as capture_viewport or viewport_light, nor when not to use it. The backend caveats are behavioral context rather than explicit usage 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?

With readOnlyHint=true already covering scene safety, the description adds real context: it writes a file to disk, the file is grep-friendly, and it returns the path rather than the data. It does not warn about output size on large scenes or overwrite behavior of a prior dump.

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

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

Three short sentences, front-loaded with the action and format, followed by content scope and the follow-up step. Minor noise from leading indentation but no wasted sentences.

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

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

An output schema exists, so the return value need not be explained, and the description still clarifies it is a file path examined via Read. For a 5-parameter tool with full schema coverage this is nearly complete, only lacking guidance on output size or whether it overwrites existing dumps.

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 root, max_depth, filter_types, property_filter and include_properties each documented in the schema. The description adds nothing about parameters, so baseline 3 applies — the schema does all the work.

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

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

States a specific verb and resource: dumps the full scene graph into a prim-block text file with prims, properties, bounding boxes and transforms. An agent can tell this produces a file artifact rather than an in-memory result, distinguishing it from get_scene_tree or get_prim_properties, though no sibling is named explicitly.

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

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

The description gives a clear operational recipe: call this, then use the Read tool to inspect specific parts of the grep-friendly file. That implicitly frames it as the choice for full-scene inspection, but it never says when to prefer export_prim_as_file or get_scene_tree instead.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the risk profile is covered structurally; the description adds substantial context beyond that: the script runs in the live app, runs automatically as async, stdout/stderr are captured, and each mcp call returns a dict with status/result. It stops short of stating timeouts, error propagation, or that script effects on the scene are irreversible.

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 purpose and execution environment, and the bulk of the length is the mcp method inventory, which is genuinely needed to write working scripts. The trailing Context7 sentence feels appended and the method list could be tightened, but there is little waste.

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

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

For an arbitrary-code escape hatch with an output schema, the description covers the environment, importable modules, the return convention, async semantics, and the full bridge API surface. Nothing essential for calling it correctly is missing.

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

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

Schema coverage is 100% and the single 'code' parameter is already documented as 'assign to result to return data'. The description's module list and mcp method signatures add real meaning for what can be written in that parameter, but the baseline for a fully covered single-param schema is 3.

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

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

States a specific verb and resource: execute Python inside the running Kit app, and names the host environments (Isaac Sim, USD Composer). However, it never contrasts itself with the many granular siblings (create_prim, set_material, sim_control), so the agent must infer that this is the general escape hatch rather than a specialized tool.

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 clear guidance on how to write the script (assign to 'result', use await, look up APIs via Context7 MCP), but nothing on when to pick this over the ~40 sibling tools that do the same operations individually. Usage is implied by capability listing rather than by explicit routing or exclusions.

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

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

Annotations already declare destructive=true and readOnly=false, and the description adds real behavioral detail beyond them: references are resolved and materials outside the subtree are pulled in, so the output is a flattened, self-contained artifact. It stops short of saying whether output_path is overwritten or whether the destination directory must exist, which matters for a destructive write.

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

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

Three short sentences, front-loaded with the action, and every sentence carries information. Minor waste in restating 'Flattens the source (resolves all references)' and 'Output is self-contained' which overlap.

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 annotations cover the safety profile. For a two-parameter export tool the description gives enough on flattening and material inclusion to call it correctly.

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

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

Schema description coverage is 100%, so the schema already explains prim_path and output_path, including the .usd/.usda/.usdc default. The description adds conceptual meaning (the subtree is flattened, external materials are included) but no new per-parameter syntax or constraints, so baseline 3 applies.

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

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

The description opens with a specific verb and resource ('Export a prim subtree as a standalone USD file') and the follow-up sentence clarifies the export semantics (flattened, self-contained). It does not, however, distinguish itself from the sibling flatten_usd, which sounds like it does the flattening step alone.

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 self-contained/standalone framing implies the use case (producing a portable asset), but there is no explicit when-to-use, when-not, or pointer to flatten_usd or save_scene as the alternative. The agent must infer the boundary from the phrase 'standalone USD file'.

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 adds real semantic context about what flattening does to composition arcs, which annotations do not convey. However, annotations already flag destructiveHint=true, and the description never states the key destructive risk: that output_path is written and may overwrite an existing file, nor whether the source stage or current session is left unmodified.

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 the definition of flattening. The trailing indented block is slightly awkward formatting but contains no wasted language.

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

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

Output schema exists, so return values need not be explained, and both parameters are fully documented in the schema. What remains missing for a destructive write tool is the overwrite/validation behavior on output_path and whether the open stage is altered, leaving the agent to guess at side effects.

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

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

Schema description coverage is 100%, so the baseline is 3. The input_path default behavior restated in the description ("the open stage when empty") duplicates the schema text verbatim in substance, and output_path receives no additional semantics such as overwrite behavior or directory creation.

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 ("Flatten a USD file") and then defines what flattening means by naming the composition arcs resolved (references, payloads, sublayers). An agent can tell this apart from export_prim_as_file or dump_scene by the arc-resolution framing, though no sibling is named explicitly.

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

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

The note "If input_path is omitted, flattens the current stage" gives one concrete usage mode, but there is no guidance on when to prefer this over dump_scene, export_prim_as_file, or save_scene, nor any stated exclusions or prerequisites (e.g. requiring a loaded stage).

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds substantial context beyond that: units (radians, metres, per-second velocities), a failure mode while stopped, and the Isaac Sim 6.2 dependency. Only the return shape is left to the output schema.

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

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

Front-loads the core purpose and keeps to a few efficient sentences. The parenthetical unit caveat is dense but earns its place by preventing a degrees/radians mistake.

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

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

For a single-param reader with an output schema and full annotation coverage, the description supplies the missing behavioral context (units, sim-state precondition, dependency). Return format is legitimately left to the output schema, so nothing critical is absent.

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?

With a single prim_path parameter at 100% schema coverage, the schema fully documents the argument. The description adds nothing about prim_path beyond what the schema already states (root prim, example path), 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 (Get) and resource (joint positions and velocities) with unit semantics, and explicitly distinguishes itself from set_joint_targets. An agent can tell what it returns and how it differs from the setter sibling without opening the schema.

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

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

Gives the operative condition (works while sim plays or is paused; errors while stopped) and names the alternative set_joint_targets with its differing unit convention (degrees). This is explicit when/when-not/alternative 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?

Goes well beyond the readOnlyHint by disclosing the log's origin (file since extension start), the default verbosity floor ('Info and above'), and the non-obvious prerequisite that verbose lines require Kit to be launched with --/log/level=verbose and --/log/fileLogLevel=verbose. Only the return shape/pagination is left unstated, which the output schema covers.

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 action and scope, then the usage trigger, then the verbosity caveat — a logical progression where every sentence carries information. Slightly longer than strictly necessary, but nothing 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?

Covers purpose, trigger, and the one genuinely surprising behavior (verbose logging requires startup flags). With an output schema and full parameter coverage plus safety annotations, the only omission is how much history is guaranteed versus the 2000-entry buffer, which the schema already hints at.

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 count, search, channel, and min_level are already fully documented, giving a baseline of 3. The description adds a little context by explaining what the log contains by default, which indirectly informs min_level usage, but it does not explain parameter interaction or filtering precedence.

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

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

States a specific verb and resource (get recent entries of the Kit app's log) and pins down the scope further: read from the log file since the bridge extension started. No sibling tool does anything similar, so the agent can immediately tell this is the diagnostics/log surface.

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

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

Gives an explicit trigger condition: 'when any tool fails, call get_logs() to see what the Kit app reported.' That is precisely the when-to-use guidance an agent needs, and there is no competing alternative to route away from.

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?

readOnlyHint=true and openWorldHint=false already tell the agent this is a safe, local read. The description's claim that it "returns per-mesh breakdown and totals" is largely redundant with the output schema. It says nothing about how non-mesh prims or empty subtrees are handled, or about cost on large subtrees.

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 lines, front-loaded with the core capability. The closing "etc." is mild filler but does not undermine the structure.

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

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

For a single-parameter read tool with annotations and an output schema, the description covers purpose, scope, and intended use. Only the sibling disambiguation from get_prim_face_count_tree and non-mesh prim handling are 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?

Only one parameter, and the schema covers it at 100% coverage, including the note that descendant meshes are included. The description's "prim or subtree" matches the schema without adding new semantics, so the baseline of 3 is right.

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: counts of faces, vertices and triangles for a prim or its subtree. That is concrete enough to act on. It does not differentiate itself from the close sibling get_prim_face_count_tree, so an agent comparing the two still has to guess.

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

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

"Use for measuring geometry budget, shell reduction ratios" gives concrete motivating scenarios, which is more than most definitions. It stops short of exclusions or naming an alternative, so the overlap with get_prim_face_count_tree is left unresolved.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds the returned bounding-box components, but it omits important spatial semantics such as whether the box is world-space or local-space and whether child prims are included.

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

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

The description is two short sentences, front-loads the core operation, and uses no wasted wording.

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

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

For a simple read-only tool with a fully documented single parameter, annotations, and an output schema, the description is largely complete. The main gap is that it does not clarify coordinate-space behavior for bounding-box calculations.

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 prim_path is documented with an example in the schema. The description does not add further meaning about prim_path beyond what the schema already provides, so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Get the bounding box of a prim,' and enumerates returned components like center, dimensions, min/max corners, and diagonal. It is clearly distinct from siblings such as get_prim_properties, though it does not explicitly route agents away from alternatives.

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 usage context: 'Use this for spatial reasoning -- understanding sizes, overlap, distances.' This tells the agent when the tool is appropriate, but it does not name exclusions or alternative tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context about what each node returns (per-mesh face/vertex/triangle counts, per-group subtree_faces totals), though it omits any warning that counting faces over a deep tree may be expensive on large scenes.

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 purpose and followed by the sibling comparison. Slight redundancy between the first line and the 'each mesh shows...' clause, but nothing is wasted.

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

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

With an output schema present, the description needn't detail return values, and the two parameters are fully documented in the schema. The only meaningful gap is absence of any performance/cost note for deep or large trees, which matters for a face-counting traversal.

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 root and max_depth are fully documented in the schema. The description adds no additional meaning about these parameters (no guidance on depth cost tradeoffs), so the baseline 3 applies.

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

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

States a specific verb and resource ('Get scene tree with face counts per mesh and subtree totals') and explicitly distinguishes itself from the sibling get_scene_tree by scope. An agent can pick between the two without opening either schema.

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

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

Names the closest alternative (get_scene_tree) and gives the condition that selects this one: geometry budget / face counts. It stops short of explicit when-not guidance (e.g., 'don't use for single-mesh stats, use get_mesh_stats'), but the routing signal 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely useful context the annotations do not — the output is prim-block text, not structured data, and is "grep-friendly" with type, position, bounding box, and all USD properties. It omits failure behavior for an invalid prim path, which keeps it from 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?

Two short sentences with zero filler, front-loaded with the action and resource before the return-format detail. Every sentence earns its place.

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

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

An output schema exists, so return values need not be enumerated, and annotations plus the format note cover the important quirks (text output, grep-friendly). The only real gap is undefined behavior on a nonexistent prim path, which is minor for a read-only single-parameter tool.

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

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

There is a single parameter with 100% schema description coverage including a concrete example path ("/World/Robot"), so the schema carries the semantics. The description adds nothing about the parameter, which matches the baseline 3 for fully documented 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 and resource (get all properties of a specific prim) and scopes it ("all USD properties"), which implies a distinction from narrower siblings like get_prim_bounds or get_mesh_stats. It never names an alternative, so it stops short of a 5, but an agent can tell what it returns without opening the schema.

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

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

Usage is only implied by the phrase "all properties" — there is no explicit when-to-use, no prerequisite, and no routing to nearby siblings such as inspect_prim or get_prim_bounds. Adequate but leaves the choice between overlapping readers to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds one useful behavioral fact not in the annotations — the frame is materialized as a PNG file — but it omits where that file lands, whether it is returned as a path, and whether repeated calls overwrite the same artifact. There is mild tension between "Saves as PNG file" and readOnlyHint, though it reads as a non-mutating export rather than a contradiction.

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, with no filler. The second sentence is slightly orphaned because it states a file is saved without saying where, but nothing is wasted.

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

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

For a simple two-parameter read tool with an output schema and full annotation coverage, the description is adequate to call it. It stops short of telling the agent what the PNG side effect means practically — output location, overwrite behavior, or dependence on an active/stopped recording — which matters given the sibling recording tools.

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

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

Schema description coverage is 100%, so both frame_index (0-based) and session_dir (empty means last recording) are already fully documented in the schema. The description adds only the notion of a "recording session" that frames belong to, which does not go beyond the schema's own wording. 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?

"Get a specific frame from a recording session" gives a concrete verb and resource, and the second sentence clarifies the output form (PNG). It is distinguishable from mutating siblings like start_recording/stop_recording, but it never contrasts itself with the other capture-style sibling (capture_viewport), leaving a small ambiguity about which screenshot-like tool to pick.

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

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

The phrase "from a recording session" implies the precondition (a session must exist), but there is no explicit when-to-use statement, no mention of start_recording/stop_recording as prerequisites, and no exclusion of the alternative capture_viewport. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces it ('Get', 'Pure USD') while adding a genuinely non-obvious trait: it works without a running simulation because it reads USD data directly. It does not mention performance, caching, or failure modes when the prim is not a robot.

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 clauses, zero filler, with the output fields front-loaded and the sim-independence caveat second. Every word 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?

A simple one-parameter read tool with an output schema that covers return values. Description supplies the field list and the no-simulation constraint, which is everything an agent needs to call it correctly.

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

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

Only one parameter and schema description coverage is 100% with a concrete example ("/World/G1"), so the schema carries the load. The description adds no meaning about what prim_path must point to (robot root vs. articulation root) beyond what the schema already says.

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

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

Specific verb+resource ('Get robot joint info') followed by an enumeration of the returned fields (names, types, limits, DOF count). 'Pure USD, no sim needed' implicitly separates it from get_joint_states / get_sim_state, though it never names the sibling.

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

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

'Pure USD, no sim needed' implies the condition for choosing this over a simulation-state tool, but usage is left to inference. No explicit when-to-use or when-not statement and no named alternative.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value by describing the shape of the returned text (path, type, world position per prim) and flagging the scale trade-off, though it says nothing about truncation or cost at depth 15.

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

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

Two tight sentences, front-loaded with the core purpose and output format, then the sibling pointer. Nothing is repeated 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 needn't explain return values, and annotations cover safety; what it adds — the textual format and the dump_scene alternative — closes most of the gap. The remaining weakness is the ambiguous scale guidance rather than missing core information.

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

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

Schema coverage is 100% and both parameters are self-documenting, so the schema carries the load. The description only implies that depth/scope matter via the 'large scenes' remark and adds no format or semantics beyond what 'Root' and 'Max Depth' already state; baseline 3 applies.

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

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

States a specific verb and resource ('Get the USD scene hierarchy') plus the exact output form ('grep-friendly prim-block text'), and names what each entry contains (path, type, world position). This makes it clearly distinguishable from get_prim_properties, get_prim_bounds, and dump_scene without opening a schema.

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

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

It names one alternative (dump_scene) for larger scenes, which is better than nothing. However, the recommendation is counterintuitive — dump_scene 'also includes properties and bounding boxes', i.e. more data for exactly the case where volume is already a problem — and no when-not condition or depth guidance is given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds that it surfaces version mismatch and remediation steps, but that field list largely mirrors what the output schema already documents, leaving little behavioral context beyond the structured data.

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 delivers the core purpose first and then the field list. The field enumeration partially duplicates the output schema, which keeps it from perfect efficiency, but there is no filler.

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

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

With zero params, full annotation coverage, and an output schema, the description needs only to orient the agent, which it does. The version-difference guidance is a useful extra; nothing essential for calling 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?

The tool takes zero parameters, so the schema baseline is 4. There are no arguments whose meaning needs elaboration, and the description correctly focuses on the returned state rather than inventing input semantics.

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

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

States a specific verb ('Get') and resource ('simulation state') and then enumerates exactly what it returns: play state, time, FPS, prim count, up axis, and Kit/server versions. This read-only enumeration clearly contrasts with the sibling sim_control, which mutates that state, so an agent can choose between them without opening either schema.

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

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

The read-only framing implies when to use it (inspecting simulation status), but there is no explicit when-to-use, prerequisite, or named alternative such as sim_control for changing state. The only conditional guidance ('what to run when they differ') concerns version remediation, not tool selection.

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

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

Goes beyond the annotations by disclosing that PNG files are written to disk (explaining why readOnlyHint is false despite being nominally a capture), that the camera is auto-fitted with a ~10px margin, and that isolate temporarily hides and then restores other objects. It stops short of stating where files are saved or how they are named.

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 sentences, front-loaded with the core action and followed by the key behavioral facts (auto-fit, coverage, file output, Read hint). No filler, though the awkward line breaks and indentation slightly hurt scanability.

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 and all 7 parameters documented, the description covers behavior adequately. The one real gap is the output file location/naming convention, which the agent needs in order to actually Read the PNGs it just produced.

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 every parameter already carries its own description including the full angle-name list and zoom_offset semantics. The description adds only the confirming detail that all 14 angles are captured by default, 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: 'take screenshots from 14 systematic angles around a prim', with the exact composition of those angles (6 face centres + 8 cube corners). This is clearly distinguishable from sibling tools like capture_viewport or look_at_prim, which do not imply multi-angle orbit capture.

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 (visual inspection of a prim) and the description adds a useful post-step hint ('Use Read tool to view images'), but it never states when to choose this over capture_viewport, look_at_prim, or compare_prims. No exclusions or alternatives 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?

Annotations declare readOnlyHint=false and destructiveHint=false, so the mutation profile is already carried structurally. The description adds useful behavior not in annotations: distance is auto-computed from object size when omitted, and it makes clear the prim itself is not transformed, only the camera.

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 verb and resource, followed by two compact clarifying lines. The azimuth convention line partly duplicates the schema and could be trimmed, but nothing is bloated.

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

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

With full schema coverage and an output schema present, the description needn't explain parameters or return values. It covers the non-obvious distance fallback and angle convention; only the lack of any note on persistence/undo of the camera change keeps it from a 5.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds a small amount (270=left, which the schema omits, and the auto-distance rule), but azimuth/elevation/distance semantics are largely already documented in the schema.

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

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

States a specific verb and resource: 'Point the viewport camera at a prim from a given angle.' An agent can understand the operation immediately, but the description never distinguishes it from the nearby sibling set_camera, which likely also manipulates the camera.

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

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

Usage is only implied by the description of the framing behavior; there is no explicit statement of when to prefer this over set_camera or capture_viewport, nor any preconditions such as an open viewport or loaded scene.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds nothing to that picture — it never says disabling may disrupt the running app, whether changes persist across restarts, or that only the enable/disable branches are destructive while list is a safe read. The description is consistent with annotations but contributes no behavioral context of its own.

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 but arguably too terse for a tool that bundles a safe read action with a destructive mutation action.

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

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

An output schema covers return values, but for a tool annotated destructive the description should at minimum say which branch is destructive and what the consequences of disabling are. With zero required parameters and three distinct modes, the description leaves the agent to infer too much.

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 each parameter carries its own description, so the schema already does the work. The description mentions the three actions but does not link them to extension_id or explain that search/enabled_only only apply to the list action. 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 three specific verbs (list, enable, disable) against a specific resource (the Kit app's extensions), which is enough to separate it from every sibling tool, none of which touch extensions. It stops short of 5 because it never clarifies what an 'extension' means in this context or what the tool returns.

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

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

There is no guidance on when to pick each action, no mention that enable/disable require extension_id while list does not, and no indication of risk or prerequisites. The implied usage is only that the tool exists.

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

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

The annotations already declare destructiveHint=true, so the agent knows this is destructive. The description adds useful behavioral detail (empty scene, /World root, Y-up axis) but does not explicitly state that the current scene is discarded or that unsaved work will be lost.

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

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

It is a single front-loaded sentence with no wasted words. The key creation behavior and scene attributes are stated immediately.

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 zero-parameter schema and output schema mean little return-value explanation is needed, and destructiveHint covers the safety profile. However, for a destructive scene-reset tool, the description should more explicitly warn that the existing scene is replaced; the current text only implies it via 'fresh empty scene'.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly introduces no parameter concepts and instead describes the fixed output scene structure.

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

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

The description states a precise verb and resource ('Create a fresh empty scene') and specifies the resulting scene contents ('/World root prim and Y-up axis'), which distinguishes it from sibling creation tools like create_prim. An agent can tell exactly what this tool produces.

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

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

There is no explicit guidance on when to use this versus save_scene, delete_prim, or other scene-management siblings. Usage is only implied by the verb 'Create'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that it returns hit results, but says nothing about coordinate space (world vs local), what kinds of geometry are hit, or whether the ray stops at the first hit or returns all hits.

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

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

Two short sentences with the core action front-loaded. The second sentence is mild filler but not harmful.

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 all three parameters are documented, so the description only needs to frame the operation. The one meaningful omission is the coordinate frame of origin/direction, which matters for a 3D ray query.

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%, including the note that direction is normalised and the default max_distance of 1000. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource: cast a ray into the scene and return the hit result. That is clearly distinct from siblings like get_prim_bounds or inspect_prim, though the description never names an alternative to reinforce 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?

'Useful for spatial queries' implies the use case but gives no explicit when-to-use or when-not-to-use guidance, and no alternative is named for agents deciding between raycast and get_prim_bounds or get_prim_properties.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds nothing on the safety side. The critical behavior — that an empty file_path overwrites the stage's own file in place — is documented only in the schema, not the description, even though it is the main risk an agent needs flagged before calling.

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?

One short sentence with the action and target front-loaded; no filler. It is appropriately sized for a single-parameter 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?

Output schema exists and annotations cover the safety profile, so the description needn't explain return values. But for a destructive save operation, the in-place-overwrite behavior and any distinction from other file-producing siblings should be surfaced in the description itself, not left to schema inspection.

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 is documented as 'The USD file to write; empty overwrites the stage's own file,' so the schema fully carries parameter semantics. The description adds no format, extension, or path-resolution guidance beyond that, making the baseline 3 appropriate.

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

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

States a specific verb ('save') and resource ('current scene') with the target format ('USD file'), so the core action is unambiguous. However, it does nothing to distinguish itself from siblings like export_prim_as_file, flatten_usd, or dump_scene, all of which also produce files from scene data.

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

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

There is no indication of when to use this versus export_prim_as_file or flatten_usd, nor any prerequisite (e.g., must edits be committed, does it validate the stage first). The agent is left to infer usage entirely from the name.

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

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

Annotations already communicate that this is a non-read-only, non-destructive, closed-world mutation. The description adds that the camera is a 'viewport camera' and that aiming at a target is optional, which is useful context, but it does not describe side effects such as whether the change is persistent, undoable, or affects saved scenes.

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 language. Every clause earns its place by stating the main action and the optional aiming behavior.

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 and full schema descriptions for the two parameters, the description need not explain return values. It adequately covers the core behavior for a simple camera-setter, though it could be stronger by mentioning how it relates to look_at_prim or whether camera changes persist.

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

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

Schema description coverage is 100%, so both parameters are already documented as [x, y, z] vectors. The description only restates that position and optional target exist, adding no format or behavioral detail beyond what the schema provides.

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

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

The description states a specific verb and resource: 'Set the viewport camera position' and optionally aim it at a target point. This is clear action but does not explicitly differentiate from the sibling look_at_prim, which also aims the camera, so it falls 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 description implies when to use the tool, namely to position the viewport camera and optionally aim it. However, it gives no explicit guidance on when to prefer this over alternatives such as look_at_prim, nor does it state any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one valuable behavioral fact—it works without articulation initialisation—but does not explain side effects, partial target behavior, or what happens with null/omitted targets.

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

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

Two short, front-loaded sentences with no waste. The main purpose comes first, and the special capability follows immediately.

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 simple two-parameter schema, full parameter descriptions, annotations, and an output schema, the description covers the essential non-obvious behavior. Minor gaps remain around null/partial targets and target unit expectations, but the schema handles most of that.

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 schema fully explains targets format and units as well as prim_path. The description adds no parameter-level meaning beyond the schema, so the baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Set joint drive position targets.' This clearly distinguishes a write operation from sibling readers like get_joint_states, though it does not explicitly name alternatives or differentiate from set_prim_transform/sim_control.

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 'Works without articulation initialisation' implies a useful usage condition—this tool can be called before articulation setup. However, it does not state when to use this tool versus alternatives like sim_control or get_joint_states, leaving usage largely inferred.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds that a material is created automatically and bound to the prim, plus color auto-detection, but it does not say what happens to an existing bound material or whether the operation can be undone.

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

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

Three short sentences, front-loaded with the action and resource. The material auto-creation detail follows logically; nothing is wasted.

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

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

With a full schema, an output schema, and annotations covering safety, the description only needs to explain the material-creation/binding behavior. It does that adequately, though it could note whether existing material bindings are replaced.

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

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

Schema description coverage is 100%, so all six parameters are documented in the schema, including color ranges, opacity, metallic, roughness, and material_path default behavior. The description's note about 0-1 floats versus 0-255 ints repeats what the schema already states, so it adds little beyond baseline.

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

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

States a specific verb and resource: applies an OmniPBR PBR material to a prim with color and surface properties. It is clearly a material-assignment tool, distinct from scene-inspection or transform siblings, though it does not explicitly contrast with update_material_paths.

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 'Apply a PBR material... to a prim', but there is no explicit when-to-use guidance, no prerequisites, and no named alternative such as update_material_paths. An agent must infer when this is the right sibling.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description's only job is added context — and it adds none. It does not say whether unspecified fields are left untouched, whether a physics material is created if absent, or whether the change is undoable.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity comes at the cost of the detail scored elsewhere.

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 annotations cover the safety profile, so the return-value and risk burden is carried elsewhere. However, for a 5-parameter mutation tool, the description omits partial-update semantics and the mass-vs-density precedence story, which is the main behavioral subtlety an agent 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?

Schema description coverage is 100%, and the field-level descriptions already explain the mass/density interaction, unset semantics, and restitution range better than any prose summary could. The description adds nothing 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 gives a specific verb and resource ("Set physics material properties on a prim"), so an agent knows exactly what operation it performs. It does not distinguish itself from siblings like set_material or set_prim_transform, which could plausibly be confused with it.

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

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

There is no guidance on when to use this versus set_material (visual/material assignment) or set_prim_transform, nor any mention of prerequisites such as the prim needing to exist or have a physics/collision API applied. Usage must be inferred entirely from the name.

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

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

Annotations already cover the safety profile (readOnly=false, destructive=false, openWorld=false), so the bar is lower, but the description adds nothing beyond them. It does not say whether omitted components are left unchanged, whether the prim must already exist, or whether the prim must be xformable.

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 short sentence, front-loaded and free of padding, but its brevity comes at the cost of under-specification rather than efficiency. It earns its place but does too little work.

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 four parameters, an output schema, and no parameter-level help in the description, critical semantics are missing: partial-update behavior, existence requirements, and failure modes. The output schema covers return values, but the mutation contract is undocumented.

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 the schema itself documenting units (metres), Euler degrees vs quaternion, and uniform vs per-axis scale. The description contributes no additional parameter meaning, 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 (set) and resource (position/rotation/scale of a prim), which clearly distinguishes it from create_prim, delete_prim, and clone_prim. It stops short of noting that components are optional, but the core action 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?

No guidance on when to use this versus siblings such as look_at_prim (which also sets orientation) or create_prim, and no exclusions or prerequisites stated. An agent must infer usage entirely from the name.

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

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

Annotations only declare it is a non-destructive, non-open-world mutation; the description adds genuinely new behavioral context — that it performs an activation toggle plus frame pumping to force a Hydra rprim refresh so the viewport shows correct geometry. That is exactly the kind of side-effect disclosure annotations cannot carry. It omits whether the operation can fail or throw, keeping it below 5.

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

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

The action and its viewport consequence are front-loaded in the first sentence, and the workaround note follows as supporting detail. The parenthetical is somewhat implementation-flavored but still earns its place by explaining an observable delay/refresh behavior.

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 three fully described required parameters, annotations covering safety, and an output schema handling return values, the only missing piece an agent needs is the side effect of the variant switch — which is documented. Nothing required for correct invocation is absent.

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 each parameter is documented with an example in the schema, so the baseline of 3 applies. The description adds no format, path syntax, or constraint details beyond the schema.

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

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

States a specific verb and resource ('Switch variant selection on a prim') and adds the viewport-refresh effect, which is the distinguishing trait versus sibling create_variant_structure. It does not explicitly name that sibling, 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 description never says when to use this tool versus create_variant_structure or create_prim, nor does it state preconditions (e.g., the variant set must already exist). Usage is only implied by the phrase 'on a prim with the variant set'.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context by noting that hiding/showing a prim also affects its descendants, which is not captured by annotations or schema.

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

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

The description is a single, front-loaded sentence with no wasted words. Every element (operation, resource, descendant scope) earns its place.

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

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

Given an output schema exists and annotations cover the safety profile, the description provides enough core information for an agent to invoke the tool correctly. It could be slightly richer with usage guidance, but the essential operation and scope are present.

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

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

Schema description coverage is 100%, with both parameters documented including an example prim path and the meaning of visible. The description does not add parameter-level detail beyond indicating that the operation applies to a prim and its descendants, 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 uses a specific verb pair (show/hide) applied to a specific resource (a prim) and explicitly states the scope includes descendants. This makes the operation clear and distinguishable from sibling tools like set_prim_transform or delete_prim.

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

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

The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It merely states the operation, leaving the agent to infer 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the mutation/safety profile is partly covered. The description adds the state-transition vocabulary but does not disclose whether 'stop' resets the timeline, whether 'step' advances exactly one frame, or whether any action blocks until completion — meaningful gaps for a control tool even with annotations present.

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?

One short sentence, front-loaded with the resource and immediately followed by the action set. Zero filler and nothing an agent must scan past to find the operative 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 values need not be explained, and annotations cover the safety profile. Still, for a simulation-control tool the description omits what each transition actually does to sim state and any preconditions, leaving the agent to guess at the effects of 'stop' and 'step'.

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 'action' parameter is a closed enum, so the schema already carries the semantics; the description merely restates the four allowed values. Baseline would be 3, but the description's enumeration confirms the enum is exhaustive and complete, adding slight practical value for a 1-parameter tool.

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

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

The description states a specific verb+resource ('Control simulation') and enumerates the exact operations (play, pause, stop, step), so an agent knows precisely what the tool does. It does not name or distinguish itself from the adjacent sibling get_sim_state, which reads simulation state rather than mutating it, so it falls short of a 5.

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

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

Usage is implied by the action list: play/pause/stop/step clearly signal the tool is for driving simulation playback. However, there is no explicit guidance on when to use this versus get_sim_state (inspect state) or set_joint_targets (drive motion), and no mention of prerequisites such as needing a loaded scene or paused state before stepping.

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

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

Annotations only say it is not read-only and not destructive; the description adds the substance: frames land in mcp_output/recordings/ as PNGs, capture cadence is about 1/fps in app updates, capture continues whether or not the sim plays, and prim state is written as grep-friendly state.txt in prim-block format. It also discloses that camera_path/width/height are currently inert and that a warning is emitted when supplied.

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 then organized into prerequisites, cadence/write location, cleanup path, and optional prim tracking. It repeats the "ignored for now (#25)" fact already carried in the schema and ends with a stray blank line, so it is slightly redundant but never padded.

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

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

For a zero-required-parameter start action with an output schema present, the description covers everything an agent needs: how to frame the shot, what will not work, where artifacts go, how often capture happens, and how to stop and inspect results. No return-value explanation is needed given the output schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description earns extra: it explains the real cadence behind fps (one frame every few app updates, ~1/fps seconds) and re-flags the three ignored parameters as a runtime warning rather than just a schema note. It adds little on property_filter beyond the schema's own example, which is why it stops short of 5.

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

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

States a specific verb and resource ("Start recording simulation frames to disk") and immediately narrows scope to the active viewport at its own size. It is clearly distinguishable from capture_viewport (single shot) and from stop_recording/get_recording_frame, which it names as the follow-up steps.

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 aim the viewport with set_camera or look_at_prim first, to play the simulation to capture motion, and to call stop_recording when done and then get_recording_frame to review. Alternatives and sequencing are named rather than inferred.

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

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

Annotations already establish that this is not read-only, not destructive, and not open-world. The description adds useful behavior beyond those hints by noting that it returns session info and frame count and that frames remain available through get_recording_frame.

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

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

The description is two short sentences with the primary action front-loaded. Every sentence contributes either the core action, the return behavior, or the follow-up tool.

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

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

For a zero-parameter tool with annotations and an output schema, the description is complete enough: it identifies the action, summarizes the return, and routes the agent to get_recording_frame for review.

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 parameter semantics are inherently simple and require no description-side explanation. The baseline for a zero-parameter tool applies.

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

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

The description states a specific verb and resource: stop the active recording session. It clearly distinguishes this action from siblings like start_recording and points to get_recording_frame for the next relevant 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?

It implies the tool is used when a recording session is active and explicitly names get_recording_frame for reviewing frames. However, it does not state exclusions or failure conditions, such as what happens when no recording is active.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds genuine value by naming what is mutated (relationship targets plus asset path attributes) and that only paths beginning with old_prefix are affected. However, it omits irreversibility, whether unmatched paths are untouched, and whether failure is atomic across the subtree.

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

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

Two short sentences with the bulk/scope statement front-loaded followed by the two mutation targets. No filler, though nothing addresses risk or failure modes.

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

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

Output schema exists so return values needn't be explained, but for a destructive bulk mutation with three parameters the description should at minimum note irreversibility and what happens to prims whose paths do not match. What's present is accurate but leaves meaningful operational gaps.

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 are documented with examples in the schema itself. The description's only extra signal is the prefix-matching behavior ('start with old_prefix'), which the schema already conveys via 'The path prefix to find'. 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 ('Bulk-update material reference paths in a subtree') and elaborates that both relationship targets and asset path attributes are rewritten. The scope is unambiguous, though it never distinguishes itself from any sibling (none of the listed siblings covers path rewriting, so the omission is minor).

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 indication of when to use this versus alternative approaches (e.g. per-prim edits or execute_script), no prerequisites such as the new location already existing, and no caution about the destructive, non-reversible nature of a bulk rewrite.

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

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

Annotations already declare destructiveHint=false and openWorldHint=false, but the description adds genuinely new context: which action is a pure read (get returns current mode, available modes, and scene lights), that set mutates state, and that set_camera_light is a legacy path. The mutation scope and legacy status are exactly the kind of extra detail annotations can't express.

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 one-line purpose followed by a scannable action list and a troubleshooting hint. The mode enumeration partially duplicates the schema's mode description, but it earns its place by being more complete than the schema's examples. Minor redundancy keeps it from a 5.

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

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

For a 3-parameter tool with full schema coverage, an output schema, and safety annotations, the description covers the remaining gaps: action semantics, mode vocabulary, legacy handling, and the practical workflow that motivates calling it. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds meaning beyond the schema by enumerating the full set of valid mode values, including light rigs ("Default", "Colored Lights", "Grey Studio") that the schema only gestures at with 'e.g.' It also clarifies that mode applies to "set" and enabled applies to "set_camera_light", reinforcing the action/parameter coupling.

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

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

Names a specific verb pair (query/control) and a specific resource (viewport lighting mode), which is clearly distinct from siblings like set_material, set_visibility, or set_camera. It doesn't explicitly disambiguate against those siblings, but the resource is narrow and unambiguous enough that no confusion arises.

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

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

Gives a concrete trigger scenario: when capture_viewport returns a black image, use this tool to check/change lighting and then recapture. It also explains what each of the three actions is for. It stops short of stating when not to use it (e.g. lighting vs. exposure or camera clipping), so it falls short of a 5.

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