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

No annotations are provided, so the description must carry the full behavioral disclosure burden. It communicates that this is a binding/mutation operation but does not explain whether existing bindings are replaced, whether changes persist, what side effects occur, or whether any permissions are needed.

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

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

The description is concise and well structured: a clear one-sentence purpose followed by a compact args list. There is no filler and all information is relevant.

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 core parameters are covered and an output schema exists, so return value details are not needed. However, with no annotations, the lack of side-effect disclosure and relationship to related material tools leaves the context incomplete for an agent making routing or safety decisions.

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

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

Schema description coverage is 0%, and the description compensates well for the three core parameters by explaining material_path, target_prim_path, and material_purpose values. It omits the auxiliary command_id and idempotency_key parameters, but these are generic and less critical for correct invocation.

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 an unambiguous action: 'Bind a material to an object.' It clearly identifies both the resource being applied and the target, and it is easily distinguished from sibling tools like create_material and get_material_binding.

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 tool's usage is implied: it is used when a material and a target object prim already exist. However, it does not explicitly state when to prefer this over alternatives like get_material_binding, nor does it give 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?

With no annotations, the description carries the behavioral burden and does a good job: it discloses atomicity, failure rollback ('any failed operation restores the stage snapshot'), and the preview/apply dual mode. It does not mention permission requirements or side effects beyond the stated atomic transaction, but the key failure semantics are clearly provided.

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 sentences with no filler. The primary capability is front-loaded, the batch limit is stated, and the most important behavioral guarantee (atomic rollback) is included. 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?

For a complex batch mutation tool with no annotations and 0% schema coverage, this is not complete enough. The description conveys the broad contract but leaves the agent unable to correctly construct 'operations' objects or understand the auxiliary parameters. While an output schema exists, the input semantics are too underspecified for reliable autonomous invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the opaque schema. It broadly characterizes the operations as layer/arc/variant/semantic/attribute edits, but it does not explain the structure of each operation object, the meaning of preview, command_id, idempotency_key, or readback_root_path. The additionalProperties: true schema leaves these critically under-specified.

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 ('apply' or 'preview'), a clear resource ('stage batch'), a capacity (up to 100 edits), and the kinds of edits covered ('layer/arc/variant/semantic/attribute'). This clearly distinguishes it from the many single-edit siblings like edit_sublayer and set_variant_selection.

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 batch usage by mentioning 'up to 100' edits and atomic apply, but it never explicitly says when to choose this tool over calling individual edit tools. It also hints at a preview-then-apply workflow without spelling it out as a recommended sequence.

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

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

With no annotations, the description carries the burden and does disclose two useful behaviors: the operation waits for a bounded amount of time so it shouldn't hang, and it defaults to preview mode. However, it doesn't say whether baking modifies the stage persistently, whether preview avoids all side effects, or how failures or timeouts surface. That missing side-effect and error context keeps this at a 3.

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 sentence with no filler; verb, resource, wait behavior, and preview default are all front-loaded. It is as compact as possible while communicating the core 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?

The definition is adequate as a high-level summary, but incomplete for a tool with 4 parameters and no annotation safety profile. It doesn't explain preview semantics, the meaning of command_id/idempotency_key, or failure behavior, despite having an output schema to describe results. An agent would need to infer or experiment to call it correctly in a non-default scenario.

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

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

Schema description coverage is 0%, so the text must explain the 4 parameters; it only loosely maps 'bounded wait' to max_frames and re-states the preview default. command_id and idempotency_key are completely unaddressed, so an agent cannot know how to set them or why they exist.

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

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

The description names a concrete operation ('Bake'), a specific resource ('current stage NavMesh'), and key behavioral qualifiers (bounded wait, preview by default). This makes it easy for an agent to identify what the tool does. It doesn't explicitly call out sibling tools, so it doesn't fully earn the top score.

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

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

No guidance is given about when to bake versus checking status or using other navigation tools; there is no reference to get_navmesh_status or prerequisites such as having a valid stage or agent. The 'preview by default' hint implies a safe/test usage but does not state when to set preview to false. This leaves usage decisions to the agent.

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

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

With no annotations, the description at least discloses that this is a cancellation request and that it returns an unspecified but predictable terminal lifecycle state. It still leaves side effects, async behavior, idempotency, and failure semantics undisclosed, so the coverage is thin.

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

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

The description is one terse sentence with no filler and front-loads the main action. It is concise, though it sacrifices helpful detail needed 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?

For a no-annotation tool with three unevaluated parameters, the description covers only the core outcome. The presence of an output schema reduces the need to explain returns, but the agent still lacks enough about optional parameters and sibling disambiguation to call the tool 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 0% and the description adds no meaning for job_id, command_id, or idempotency_key. job_id is inferable from the tool name and required status, but the optional command_id and idempotency_key roles are unexplained.

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 the specific action 'request cancellation' and indicates a job lifecycle outcome, so an agent can see this is a job-cancellation operation. It does not explicitly name the job resource or differentiate from siblings like cancel_sdg_job and cancel_motion, keeping it from 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 gives no guidance on when to choose cancel_job over alternatives such as cancel_sdg_job, cancel_motion, stop_simulation, or whether this complements get_job_status. Without exclusions or context, the agent must infer applicability.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It does explain the main effect—canceling and holding the last commanded position—which is useful. However, it does not disclose reversibility, error behavior, or consequences for already-completed jobs, leaving meaningful behavioral gaps.

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 sentence that states the core purpose and key behavior without filler. It is front-loaded with the action and resource, making it easy to scan.

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 cancel operation with no annotations and three undocumented parameters, this description is incomplete. It names the core behavior but lacks guidance on optional parameters, edge cases, and how it differs from related cancel tools. An agent could invoke it with only job_id, but would have limited understanding of command_id, idempotency_key, or failure modes.

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

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

The schema provides no descriptions for any parameters, and schema description coverage is 0%. The description does not explain command_id or idempotency_key at all, and only indirectly identifies job_id as the motion job identifier. It adds essentially no parameter-level meaning beyond the schema's field names.

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

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

The description clearly states the specific action: cancel a running motion job. It also adds a meaningful behavioral detail—holding the last commanded position—which distinguishes it from the generic cancel_job and cancel_sdg_job siblings.

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 the tool is for motion jobs in a running state, but it provides no explicit guidance on when to prefer cancel_motion over the sibling cancel_job, nor what to do if the job is not running. There are no alternatives or exclusion conditions mentioned.

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

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

With no annotations, the description carries the full burden. It usefully discloses that resources detach at the next safe point, indicating asynchronous/delayed cancellation behavior. However, it does not clarify the default preview=true behavior, what side effects a real cancellation has, or whether execution is reversible.

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 extremely concise and front-loaded, with no filler. The key distinction (preview vs. request) appears first, followed by the important async 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?

For a cancellation tool with no annotations and 0% parameter coverage, this description is under-specified. It omits the meaning of the preview flag, the role of command_id and idempotency_key, and does not explain what the output or actual cancellation entails.

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

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

Schema description coverage is 0%, and the description provides no information about job_id, preview, command_id, or idempotency_key. An agent must guess which parameters control the preview-versus-execute behavior and how idempotency works.

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

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

The description states a clear action ('Preview or request cancellation') on an identifiable resource (SDG job, via the tool name). It conveys the core purpose and the unusual preview capability. However, it does not explicitly distinguish itself from the sibling cancel_job tool beyond the name itself.

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 'Preview or request cancellation' implies a preview-then-execute workflow, which offers some usage guidance. It does not explain when to prefer this tool over cancel_job or delete_sdg_job, and no when-not-to-use guidance is provided.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does reveal meaningful non-obvious behavior: output_path is for artifact mode, inline_max_bytes caps inline mode at 4 MiB, and return_mode defaults to artifact. However, it does not explain side effects of artifact mode, what metadata mode returns, or any failure conditions, so coverage is partial.

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 compact and front-loaded with the core purpose, then presents parameters as a tight list. Each listed parameter earns its place with a concrete detail, with no filler or redundancy. It loses a point mainly for not being structured into behavioral prose.

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 description is reasonably complete for the main capture workflow given that an output schema exists, so return values are covered elsewhere. But two schema parameters are undocumented, and there is no context on output modes or artifact side effects, which matters more because no annotations 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 0%, so the description must compensate. It adds value for 5 of 7 parameters: prim_path, output_type with allowed values, output_path purpose, return_mode options/default, and inline_max_bytes cap. It omits command_id and idempotency_key entirely, leaving those two params unexplained.

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 ('Capture a typed RTX camera annotator output') and enumerates the distinct output types (depth, segmentation, normals, motion_vectors), which makes its scope clear. It does not explicitly differentiate from sibling tools like capture_image, but the term 'typed annotator output' plus the listed modes is enough to set it apart.

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

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

No guidance is given about when to use this tool versus alternatives such as capture_image, read_artifact, or get_artifact_info. The description covers parameter mechanics but says nothing about selection criteria 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?

With no annotations, the description partially carries the behavioral disclosure burden. It explains return_mode behavior, the managed artifact root for output_path, and the 4 MiB inline limit. However, it does not clarify potential side effects, storage implications, error conditions, or whether camera setup is required.

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 compact and well-structured: a one-sentence purpose followed by a concise Args list. Every line provides useful information, and the most important behavioral details are front-loaded. There is no filler or redundancy.

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

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

The description covers core operational details like output modes and path handling, and an output schema exists to describe return values. However, it lacks usage context relative to its sibling capture_camera_output and does not state prerequisites, making the overall guidance incomplete for a camera-related tool.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for prim_path, output_path, return_mode, and inline_max_bytes, including defaults and constraints. However, command_id and idempotency_key are left entirely unexplained, leaving two parameters under-documented.

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

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

The description clearly states the tool's primary function: 'Capture an RGB image from a camera sensor.' This is a specific verb-resource pairing that distinguishes it from generic simulation or listing tools. However, it does not explicitly distinguish itself from the similarly named sibling 'capture_camera_output', so sibling differentiation is lacking.

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 about when to use this tool versus alternatives, no prerequisites, and no mention of sibling tools such as capture_camera_output or create_camera. An agent has to infer usage solely from the function name and parameter defaults.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action (delete) and a summary output (reclaimed capacity), but does not disclose whether deletion is permanent, how 'managed' is defined, what happens to active artifacts, or how the optional parameters affect behavior.

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, compact sentence that front-loads the main action and then the reported outcome. Every word contributes meaning, with no redundant or filler content.

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

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

Despite having an output schema, the description is incomplete for a tool with two optional parameters and no annotations. It leaves ambiguity about the meaning and purpose of 'command_id' and 'idempotency_key', and does not clarify the operational context or side effects of the cleanup action.

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

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

Schema description coverage is 0%, so the description must compensate for the two schema parameters, but it does not. Neither 'command_id' nor 'idempotency_key' is mentioned, leaving the agent with no semantic understanding of these optional fields.

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

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

The description uses a specific verb ('Delete') and resource ('expired managed artifacts'), and adds an outcome ('report reclaimed capacity'). It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like delete_artifact, so it stops short of full differentiation.

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

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

The word 'expired' implies the tool is for cleaning up artifacts that have passed their expiration, which gives some contextual guidance. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of alternatives, and no 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?

With no annotations, the description carries the burden and does substantial work: it discloses environment removal, defaultLight preservation with a rendering rationale, and the effect of both keep flags. It does not address reversibility, unsaved changes, or interaction with simulation state, but the main destructive behavior is clearly exposed.

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 compact and front-loaded: a direct lead sentence, a focused paragraph explaining edge-case behavior, and a short Args block. Every sentence adds operational value, including the defaultLight rationale.

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

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

For a destructive, no-annotation tool, the description gives enough scenario context—environment reload cost, ground stacking, defaultLight behavior—and parameter guidance to call it correctly. It could mention unsaved-stage or simulation-state effects, but output schema and the clear core description reduce that gap.

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

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

Schema description coverage is 0%, and the description compensates for the two meaningful parameters by explaining keep_physics and keep_environment, including why keep_environment is worth passing. Generic command_id and idempotency_key are not documented, but their purpose is broadly inferable and they are not tool-specific.

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 action and resource: 'Remove all prims from the scene,' with clear qualifications about environment, defaultLight, and keep flags. It is distinct from per-prim deletion tools, but it does not explicitly distinguish itself from sibling tools like new_stage or delete_object.

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

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

Provides concrete usage context: clearing prevents create_physics_scene(floor=True) from stacking a second ground, and recommends keep_environment=True 'when clearing objects between attempts.' It lacks explicit when-not-to-use guidance and named alternatives, but gives clear situational direction.

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

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

No annotations are provided, so the description carries the full transparency burden. It states the core behavior (duplication) and one behavioral nuance (position is retained if not set), but does not disclose other relevant traits such as whether target_path must be unused, whether the clone is deep or shallow, or what happens on conflict.

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 compact and well-structured: a one-sentence summary followed by a scannable argument list. Every line adds value, and the key behavior is front-loaded.

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

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

For a simple clone operation with only two required parameters, the description is largely complete: it defines the source and target paths and the optional position behavior. The unexplained command_id and idempotency_key are a minor gap, but an output schema exists and these are likely standard platform parameters.

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 schema has 0% description coverage, so manual documentation is essential. The description meaningfully explains three parameters (source_path, target_path, position), including the default behavior for position. However, command_id and idempotency_key are left unexplained, leaving part of the schema undocumented.

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: 'Duplicate an existing object to a new prim path.' This clearly identifies the operation and distinguishes it from siblings like create_object, delete_object, and transform_object, even without naming them.

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 context is implied rather than explicit. The summary makes it clear that this tool is for duplicating an existing prim, but it does not state when to prefer it over alternatives like create_object, nor does it give 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions 'immediate target read-back,' hinting at a non-waiting return behavior, but does not explain blocking, error behavior, prerequisites, or other side effects of closing the gripper.

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

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

The one-sentence description is tightly written and front-loads the action with no filler. Every phrase adds meaning: the action, the target width source, and the immediate read-back 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?

This is a state-changing robot command with four input parameters and no annotations, so the description must cover prim_path and command/idempotency semantics. It does not, leaving an agent unable to fully determine how to target the gripper or how the command lifecycle works. The existence of an output schema helps with return values but not with input semantics.

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 schema description coverage at 0%, the description needed to explain the parameters but only relates 'profile' to the declared closed width. prim_path, command_id, and idempotency_key receive no explanation beyond their schema titles, leaving key operational details unclear.

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 verb 'close' plus 'gripper' names the action and object, and 'profile's declared closed width' adds a specific mechanism. This clearly distinguishes it from open_gripper and set_gripper_width siblings.

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 closing context but does not explicitly state when to prefer this over open_gripper or set_gripper_width, nor does it mention exclusions. An agent can infer the usage from the word 'close', but the guidance is not fully explicit.

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

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

With no annotations, the description carries the full burden and does well: it states no robot movement, specifies scalar-first quaternion order, explains reproducibility via warm-start and random seed, and discloses what the result reports. This is strong behavioral disclosure.

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

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

Three concise, front-loaded sentences with no filler. The main purpose comes first, followed by high-value behavioral details.

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

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

Despite an output schema being present, the tool has 13 parameters, no annotations, and zero schema description coverage. The description provides useful behavioral context but is not enough for an agent to correctly configure all parameters or understand required inputs.

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

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

Schema description coverage is 0%, and the description compensates for only a few parameters: target_orientation quaternion order, seed_joint_positions, and random_seed. Most of the 13 parameters, including required prim_path and target_position as well as tolerances and idempotency_key, receive no explanatory semantics.

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

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

The first sentence names a precise operation: solve bounded Lula inverse kinematics. The qualifier 'without moving the robot' clearly separates it from motion-execution siblings such as execute_trajectory or set_joint_positions.

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 usage for computing IK without commanding motion and notes reproducibility for repeated requests, but it does not explicitly name alternative tools or give when-to-use versus when-not-to-use 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?

With no annotations, the description carries most of the behavioral burden. It adds useful context like atomicity, units, collider approximation options, and the timeline precondition. It does not disclose side effects, persistence behavior, error cases, or the role of command_id/idempotency_key.

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

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

The description is compact and front-loaded. The purpose is stated in the first sentence, followed by efficient enumeration of values, units, and the precondition. No sentence 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?

Despite having an output schema, the tool has no annotations and no parameter descriptions in the schema. The description covers the core physics concepts but omits important context for command_id, idempotency_key, and collider_enabled, and does not clarify what 'atomically configure' means for partial failures or prerequisites beyond the timeline being stopped.

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

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

Schema description coverage is 0%, so the description must compensate. It explains body_type, approximation, mass_kg, and density_kg_m3, but leaves prim_path, command_id, idempotency_key, and collider_enabled semantically unexplained. This is a significant gap for an 8-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 opens with a clear verb and object: 'Atomically configure rigid/static body, collider approximation and mass.' This distinguishes it from read-only tools like get_physics_body, though it does not explicitly compare itself to sibling tools like set_physics_params.

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

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

The description provides a clear precondition ('The timeline must be stopped') and enumerates valid values, which gives an agent useful context. However, it never explains when to choose this tool over alternatives such as set_physics_params or get_physics_body, and it lacks explicit 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?

With no annotations, the description carries the behavioral disclosure burden. It does disclose that the extension validates the mode before mutating the graph and that the tool can preview, which is useful. However, it does not explain what 'configure' changes, whether the mutation is reversible, or what side effects occur beyond the graph mutation.

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

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

The description is compact and well-structured: the first sentence states purpose and scope, and the next sentences capture essential mode invariants. Every sentence earns its place 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?

An output schema exists, so return values do not need explanation, but this is a mutating tool with 8 parameters, no annotations, and no description of the required graph_path or node_path semantics. The mode constraints are essential, but the description is not complete enough for a fresh agent to safely select and invoke the tool without additional context.

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

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

The description adds valuable cross-parameter semantics: inline mode requires inline_script and forbids script_file, while file mode requires script_file and forbids inline_script. Since schema description coverage is 0%, this is important, but the description leaves graph_path, node_path, preview, command_id, and idempotency_key unexplained, so it only partially compensates for the schema gap.

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

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

The description names a specific action ('Preview or configure') and resource ('one exact ScriptNode'), and states the scope ('inline/file mode'). It is clear enough to identify what the tool operates on, but it does not explicitly differentiate from the sibling reload_script_node or other script/graph tools.

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

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

The description gives mode-level constraints but no guidance on when to use this tool versus alternatives such as execute_script, reload_script_node, or action graph tools. Usage is only implied by the resource name and the preview/configure verbs, not by clear selection criteria.

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

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

With no annotations, the description carries the burden of disclosing behavioral details. It hints at two modes, preview and connect, but does not explain what preview does, whether the connection replaces an existing one, whether the operation is reversible, or how command_id and idempotency_key affect behavior.

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 filler. Every word contributes to identifying the tool's core action and mode.

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

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

Despite an output schema being present, the description is too sparse for a tool with a preview/execute duality and optional command-related parameters. It does not clarify what 'preview' returns, when a command_id is needed, or how the tool interacts with an existing Action Graph, making it incomplete for correct invocation.

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

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

Schema description coverage is 0% and there are 6 parameters. The description adds some meaning by mapping 'source output' to source_attr and 'target input' to target_attr, but it leaves preview, command_id, graph_path, and idempotency_key semantically unexplained. The agent would have to infer the roles of several parameters.

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 action, connecting a source output to a target input within an Action Graph, and mentions the alternate preview mode. This clearly distinguishes it from sibling tools like disconnect_action_graph and delete_action_graph. However, it does not explicitly contrast with edit_action_graph or list when connecting is preferred over editing.

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

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

No guidance is provided for when to use this tool versus alternatives such as edit_action_graph, disconnect_action_graph, or evaluate_action_graph. The description also does not explain the conditions under which preview should be used instead of performing the actual connection.

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

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

With no annotations, the description carries the behavioral disclosure burden, and it does so well: it reveals that the tool uses og.Controller.edit(), auto-creates and wires OnPlaybackTick → ScriptNode for shortcuts, sets usePath/scriptPath vs inline, and that nodes/connections are ignored when script_file is set. The evaluator explanation is especially valuable, describing how 'push' keeps an OnPlaybackTick-driven ScriptNode running even when simulation is stopped. It does not mention side effects like idempotency or failure modes, but the disclosed behavior is substantial.

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 long but structured with clear sections, parameter explanations, and examples, which suits the tool's complexity. It is front-loaded with the core purpose and then elaborates on parameters. There is minor redundancy around the 'better reload story' phrasing repeated for both script_file and inline_script, but it does not significantly harm readability.

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

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

Given the tool's complexity and the absence of annotations, the description is largely complete: it covers creation mechanics, all meaningful parameter semantics, evaluator behavior, and provides usable examples. The main gaps are the undocumented command_id/idempotency_key parameters and the lack of explicit guidance about when to choose this tool over edit_action_graph or connect_action_graph.

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

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

Schema description coverage is 0%, so the description must compensate. It does for most parameters: graph_path, nodes, connections, values, evaluator, script_file, and inline_script are all explained with concrete shapes and examples. However, command_id and idempotency_key are not described at all, leaving two of nine parameters without semantic explanation.

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

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

The description clearly states the verb and resource: 'Create and wire an OmniGraph Action Graph' and explains it builds a complete graph with nodes, connections, and attribute values. It is distinguishable from siblings like delete_action_graph, get_action_graph, and edit_action_graph by framing itself as the programmatic equivalent of creating a graph in the visual editor.

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 explicit usage guidance for choosing between script_file and inline_script: script_file is recommended for iteration, inline_script for small static graphs. It also explains when nodes/connections are ignored (when script_file is set). However, it does not explicitly contrast create_action_graph with edit_action_graph or connect_action_graph, so the broader alternative-selection guidance is partially implicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only tells the agent that a camera is added and describes some parameter meanings, but it does not disclose whether an existing camera at prim_path is overwritten, whether the operation is idempotent despite the idempotency_key parameter, or what side effects occur in the scene.

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 compact and front-loaded with the main purpose, followed by a tight bullet list of arguments with no filler. Each sentence adds 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?

For a creation tool with 6 parameters, no annotations, and zero schema-level descriptions, the definition is incomplete. It fails to explain the two infrastructure parameters and omits key behavioral details like overwrite semantics and scene mutation impact, leaving an agent to guess important call context.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaningful semantics for prim_path, position, rotation, and resolution, including units and a default, but command_id and idempotency_key are left completely unexplained.

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: 'Add a camera sensor to the scene.' This clearly distinguishes the tool from camera-related siblings like create_ros2_camera_publisher or capture_camera_output, which serve different purposes.

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 about when to use this tool versus alternatives such as create_lidar, delete_sensor, or capture_camera_output. The intended usage is only implied by the tool name and one-line purpose, with no exclusions or contextual routing.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It reveals that the tool creates a group and returns a read-back, but it does not explain side effects, idempotency behavior, merge semantics, filtering behavior, or any prerequisites. For a mutation tool, this is a significant transparency gap.

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

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

The description is highly concise and front-loaded, with no filler words. However, it is so terse that it sacrifices parameter and behavior context; conciseness is good, but it borders on under-specification.

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 seven parameters, no annotations, and no parameter coverage, the description is far from complete. The output schema may cover the return value, but the description does not explain the inputs, the nature of the relationship read-back, or how merge/filter options affect behavior.

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

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

Schema description coverage is 0%, and the description adds no meaning for any of the seven parameters. Required fields like group_path and collider_paths, and optional ones like merge_group_name and filtered_group_paths, are left entirely unexplained, so the agent has no help understanding what values to provide.

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 ('Create') and resource ('USD collision group'), and notes that it returns a relationship read-back. This makes the core action clear, though it does not explicitly contrast with the sibling get_collision_group.

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 intended use is implied by the verb 'Create' — an agent can infer this is the tool to call when a collision group must be created. However, there is no explicit guidance about when not to use it or how it relates to alternatives like get_collision_group.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action. It does not disclose what happens if a sensor already exists at prim_path, whether an active stage is required, or how config interacts with the generic parameters (precedence, mutual exclusion, or override behavior) — critical unknowns for a 14-parameter mutation tool.

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

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

The one-line purpose is front-loaded and each parameter is documented on a single readable line. Some phrasing repeats ("in degrees", "Generic sensor"), but given zero schema coverage those repetitions are functional, not wasted.

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

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

An output schema exists, so return values need not be explained, but for a complex 14-parameter creation tool with no annotations and no schema descriptions, the definition still has gaps: the config-versus-generic relationship is unresolved, prerequisites (e.g., an open stage) are unstated, and two parameters are undocumented. It covers the parameter vocabulary well but not the operational context.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it adds units (degrees, meters, Hz), formats ([x,y,z], [rx,ry,rz]), a range constraint (1-100 Hz), and concrete preset examples (Example_Rotary, OS1) for 12 of the 14 parameters. It misses command_id and idempotency_key, and could clarify which parameters apply in preset mode versus generic mode.

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?

"Add a lidar sensor to the scene" is a specific verb+resource+location and clearly distinct from siblings like create_camera, get_lidar_config, or delete_sensor. However, the description never explicitly names or contrasts siblings, so differentiation is inherent in the resource rather than stated.

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

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

There is no guidance on when to use this tool versus alternatives such as create_camera, get_lidar_config, or get_lidar_point_cloud, and no exclusions are given. The only implied usage signal is the internal preset-vs-generic parameter split, which hints at two configuration modes but does not state when to choose one.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It states the creation action and notes that prim_path is auto-generated if not provided, but it does not reveal side effects such as what happens if the path already exists, whether a stage must be open, or how idempotency is handled. This is a significant gap for a mutation tool.

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

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

The description is short, front-loaded with the primary purpose, and every line in the Args block adds useful information. There is no redundant restating of schema defaults or filler text.

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

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

The description is adequate for basic use of the tool, especially since an output schema exists and return values do not need to be described. However, it lacks usage context, side-effect caveats, and explanation of command_id/idempotency_key, leaving meaningful gaps for an agent making reliable calls.

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

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

Schema description coverage is 0%, and the description compensates well by explaining 6 of the 8 parameters: light_type with allowed values, position/rotation array formats, color range 0-1, rotation in degrees, and prim_path fallback behavior. It omits command_id and idempotency_key, and does not give intensity units, but the covered parameters are meaningfully clarified.

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 clear verb and resource: 'Create a light in the scene.' It also lists the supported light types, which makes the tool's scope specific. However, it does not explicitly distinguish itself from the sibling tool 'modify_light' or other creation tools, so it stops short of full differentiation.

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

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

No guidance is given about when to use this tool versus alternatives such as modify_light, or about prerequisites like an open stage or scene. Usage is only implied by the word 'Create' and the tool name, with no explicit when-to-use or when-not-to-use context.

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

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

With no annotations provided, the description carries the full behavioral burden. It mentions that prim_path is auto-generated if not set and that certain parameters are PBR- or physics-only, but it does not disclose side effects such as whether an existing material at the path is replaced, whether the material is persistent in the stage, or what the return value represents.

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 compact, front-loaded summary followed by a clean bullet-style argument list. Each parameter line adds value with ranges or applicability notes, and there is no filler or repetition.

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

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

The material-specific parameter semantics are well covered, and an output schema exists to define returns. However, the description lacks broader context around creation behavior, overwrite semantics, and the two generic execution parameters (command_id and idempotency_key), leaving some gaps for a 10-parameter mutation tool with no annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 8 of 10 parameters with ranges, constraints, and type-specific applicability, including static/dynamic friction relationships. It omits command_id and idempotency_key, but the core material parameters are well documented.

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: 'Create a PBR or physics material.' It clearly distinguishes between the two material subtypes and separates this tool from sibling getters/appliers like get_material and apply_material.

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

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

The description gives within-tool guidance by mapping material_type to 'pbr' or 'physics' and marking which parameters apply to each. However, it does not explicitly state when to use this tool instead of alternatives such as apply_material or get_material, so usage context is implied rather than stated.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so excellently. It explains surprising behavior such as `scale` being a raw multiplier of native size rather than meters, the precedence of `scale` over `size`, and native sizes per primitive. It also discloses return values (prim_path, actual_size, bounding_box) to help the agent place objects accurately.

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 long but every section earns its place: the size/scale distinction is a critical pitfall, the return-value note is actionable, and the Args list is tidy and consistent. It is front-loaded with the primary purpose and the most surprising behavioral warning.

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 10 optional parameters, no schema descriptions, and an output schema, the description is remarkably complete. It covers supported types, units, defaults, precedence rules, and return semantics. It also gives enough coordinate and color context to invoke the tool correctly without requiring external knowledge.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning. It fully compensates by documenting object_type, position, rotation, scale, size, color, physics_enabled, and prim_path with units and behavioral notes. The only undocumented parameters are command_id and idempotency_key, which are generic execution-flow parameters and not central to object creation semantics.

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

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

The description opens with a specific verb plus resource: "Create a primitive object (Cube, Sphere, Cylinder, Cone, Capsule, Plane)." This makes the tool's scope unambiguous and clearly distinguishes it from sibling creation tools like create_light, create_robot, or create_material.

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

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

The description clearly establishes when the tool is appropriate: whenever a primitive object is needed. It also provides strong internal guidance on choosing `size` over `scale`, explaining when scale is appropriate for non-uniform shaping. It does not explicitly name alternative tools to use instead, but the context is clear enough.

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

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

No annotations exist, so the description carries the full disclosure burden. It does add valuable calling conventions — meters for positions/prismatic limits, degrees for revolute limits, [w,x,y,z] quaternion order, and allowed axis values — which prevent mis-parameterization. However, it omits side-effect behaviors such as what happens if joint_path already exists, whether body0=null means the world frame, and whether a physics scene must already be active.

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 purpose statement followed by precise format conventions. Every sentence carries information the schema lacks; there is no boilerplate, no repetition of parameter titles, and no filler.

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

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

For a 14-parameter tool with zero schema descriptions and no annotations, the description covers the highest-risk conventions (units, quaternion order, axis choices, joint types) but misses semantics needed for a correct call: body0/body1 reference meaning, whether an omitted body0 denotes the world, path formatting, and how limits apply per joint type. The output schema covers return values, but the remaining parameter gaps keep this from being complete.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully clarifies units for positions and limits, quaternion order for the local_rotation parameters, and allowed values for axis and joint_type. But it leaves other parameters unexplained: the format of joint_path, whether body0/body1 are scene paths and body0=null means world, and the semantics of collision_enabled, command_id, and idempotency_key.

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

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

The opening sentence names a specific verb ('Create'), a specific resource ('physics joint'), and enumerates the supported joint types (fixed, revolute, prismatic) plus the key feature (explicit local frames). This naturally distinguishes it from the read-oriented sibling get_physics_joint and from body-level tools like configure_physics_body.

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 offers no guidance on when to use this tool versus alternatives such as configure_physics_body or create_collision_group, and it states no prerequisites (e.g., an existing physics scene, valid body paths). An agent selecting among roughly 130 siblings must infer the use case entirely from the tool name and first 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It mentions the created ground plane and a prerequisite call, but does not disclose whether an existing scene is replaced, whether the operation is destructive, or what side effects occur. This is a significant gap for a create-style tool.

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

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

The description is short, front-loaded with the core purpose, and contains no filler. The prerequisite call is stated early, and the parameter notes are concise without duplicating every schema field.

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 description is sufficient to make a default call and understand the main parameters, and an output schema exists so return-value documentation is not needed. However, it does not explain the side effects, the difference between this and stage/scene creation siblings, or the optional command_id/idempotency_key parameters, leaving some gaps for an agent evaluating the full context.

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

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

The Args section adds meaningful meaning for gravity ('Default is standard gravity') and scene_name ('Name for the physics scene prim'), which goes beyond the bare schema titles and defaults. However, command_id and idempotency_key are undocumented in the description, and schema description coverage is 0%, so the description only partially compensates for the missing schema-level parameter documentation.

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

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

The description clearly states the verb/resource: 'Create a physics scene with ground plane.' This is specific enough to identify the tool's function and distinguish it from many siblings. However, it does not explicitly differentiate it from related scene-creation tools like new_stage or create_object.

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

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

The instruction to 'Call get_scene_info first to verify connection' gives a clear prerequisite and implies the tool should be used after confirming the stage connection. It does not state when to prefer this tool over alternatives or when not to use it, so the guidance is useful but incomplete.

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

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

No annotations are provided, so the description carries the full disclosure burden. It reveals fuzzy matching behavior, required preceding calls, and the exact returned fields with the chaining benefit to set_joint_positions. It does not disclose what happens on name/prim_path collision or mention side effects, which prevents 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?

Well-structured and appropriately sized. The purpose and key fuzzy-matching behavior come first, prerequisites are one line each, and the return-value explanation is concise. Every sentence carries useful information; 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 no annotations and moderate parameter complexity, the description covers the essential workflow: pre-conditions, fuzzy matching, parameter meanings, and return fields for immediate chaining. The output schema exists, so detailed return-value documentation is not required. The main gap is undocumented command_id and idempotency_key parameters and no explicit alternative-tool routing.

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

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

Schema description coverage is 0%, so the description must compensate for the schema. It adds real meaning for robot_type (fuzzy matched), position (xyz), name (custom prim name), and prim_path (exact path, overrides name-based path). However, command_id and idempotency_key are left unexplained in both the schema and description, leaving two parameters undocumented.

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?

Clearly identifies the verb, resource, and source library: creates a robot from the Isaac Sim asset library. Mentions fuzzy matching, which adds operational clarity. It does not explicitly compare against siblings like import_urdf or create_object, but the 'robot' and 'asset library' framing is enough to distinguish 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?

Provides explicit usage prerequisites: call list_available_robots first to see options, and call create_physics_scene before creating robots. This is strong contextual guidance. It does not explicitly state when not to use this tool or mention alternatives, so it stops short of a top score.

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

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

With no annotations, the description carries the full behavioral burden. It discloses automatic resolution of the owned render product and the override path, which is useful. However, it does not explain side effects of creating the publisher, any idempotency/retry behavior, or what 'preview' actually does at runtime.

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 three compact sentences with no filler. The primary purpose is front-loaded, and the prerequisite/override guidance is tightly packed into the remaining 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?

For a 13-parameter creation tool with no annotations, this description is too sparse. The existing output schema does not cover parameter semantics, and major aspects like preview/run distinction, default publishing behavior, and parameter effects are left unexplained.

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

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

Schema description coverage is 0%, so the description must compensate for fully undocumented parameters. It only adds meaningful context for camera_prim_path and render_product_path, leaving 11 of 13 parameters (including preview, topic_name, qos_profile, camera_type, and use_system_time) without any behavioral explanation.

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

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

The description names a specific verb ('Preview or create'), a specific resource ('ROS2CameraHelper publisher'), and the runtime context ('MCP camera runtime'). This clearly distinguishes it from sibling ROS2 publisher tools like create_ros2_tf_publisher or create_ros2_lidar_publisher.

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

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

It explicitly states that the camera prim must be created first with create_camera, providing a clear prerequisite and workflow context. It also explains when to use render_product_path as an override, though it does not contrast when to use preview vs create or when to prefer it over alternative publisher 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?

With no annotations, the description bears the full burden of behavioral disclosure. It mentions a preview/create dichotomy, implying one mode is non-mutating and the other is mutating, but it does not state side effects, default preview behavior, idempotency semantics, reset_on_stop effects, or what 'playback-driven' actually changes in the graph.

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 filler. The action ('Preview or create') comes first, and the qualifier ('playback-driven') adds distinguishing context without 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?

Given a 9-parameter tool with no annotations and zero schema description coverage, this description is far too sparse. It does not explain what a 'ROS 2 Clock publisher graph' is, how preview differs from creation, or why 'playback-driven' matters. The presence of an output schema reduces the need to describe return values, but does not compensate for missing behavioral and selection context.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It does not explain any of the 9 parameters; 'Preview or create' only indirectly maps to the preview boolean. The meaning of domain_id, graph_path, qos_profile, reset_on_stop, idempotency_key, and node_namespace is left entirely to 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 names a specific verb pair ('Preview or create') and a specific resource ('playback-driven ROS 2 Clock publisher graph'). It clearly distinguishes this tool from sibling publisher tools like create_ros2_tf_publisher and create_ros2_camera_publisher by specifying 'Clock'.

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 conveys a usage context: this is for playback-driven clock publishing, and there is a preview mode versus a create mode. However, it never states when to prefer this tool over siblings, when not to use it, or what conditions warrant preview versus 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The 'Preview or create' phrasing does hint at a dual-mode behavior, which adds some value, but it fails to explain what preview actually does, whether graphs are replaced or appended, the role of idempotency_key/command_id, or networking implications like domain_id. For a creation tool with 9 parameters and zero annotation coverage, this is a significant 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?

A single 13-word sentence with the action verb front-loaded before the resource. It is compact and efficient with no filler. It loses a point because the dual-mode behavior is jammed into one phrase without any structural hint about the default (preview defaults to true), and the jargon term 'IsaacReadJointState' is unexplained.

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

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

For a tool with 9 parameters, 2 required inputs, no annotations, 0% schema description coverage, and a crowded sibling family of ROS 2 publisher tools, this one sentence is deeply inadequate. The output schema covers return values, but the description gives the agent almost nothing needed to call the tool correctly or judge its side effects. Required inputs, default behavior, and the preview/create distinction are all left unresolved.

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

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

Schema description coverage is 0%, so the description bears the full burden of explaining parameters. It explains none of the 9 parameters: preview, domain_id, command_id, graph_path, topic_name, qos_profile, target_prim, node_namespace, and idempotency_key are all undocumented in both the schema and the description. The required parameters graph_path and target_prim are never clarified, leaving the agent to guess what prim and path are expected.

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

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

The description names a specific action ('Preview or create') and a specific resource (an 'IsaacReadJointState ROS 2 JointState publisher graph'), which clearly identifies what the tool does. The graph type named distinguishes it from sibling publisher tools like create_ros2_clock_publisher or create_ros2_lidar_publisher, though not explicitly. It loses a point because the core resource largely restates the tool 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?

No guidance is given on when to use this tool versus alternatives. The sibling set contains several ROS 2 publisher creation tools (clock, tf, camera, lidar) and delete_ros2_workflow, but the description never states selection criteria, prerequisites (e.g., simulation running, stage loaded), or when preview should be used instead of create. There is no exclusionary or comparative guidance at all.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context: the tool has preview/create dual behavior, depends on a previously created LiDAR prim, automatically resolves the owned render product, and supports an explicit override. However, it does not disclose side effects of creation, whether preview is non-mutating, or what happens to existing publishers, topics, or runtime state.

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

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

The description is compact and front-loaded with the main action. The first sentence states what the tool does, and the second sentence provides a key dependency and override behavior without filler. Some terminology could be clearer, but the length is appropriate and every sentence contributes useful 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?

For a 13-parameter creation tool with no annotations and 0% schema parameter coverage, the description is incomplete. It covers a prerequisite and one override but omits the meaning of most parameters and does not explain what preview versus create actually does in practical terms. The presence of an output schema mitigates missing return-value details, but not the large parameter and behavior 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 0% and there are 13 parameters, so the description must compensate. It adds meaning for only two parameters: lidar_prim_path (must exist, created by create_lidar) and render_product_path (explicit override for external render products). The remaining parameters such as preview, domain_id, topic_name, qos_profile, node_namespace, frame_id, and lidar_type receive no semantic explanation.

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

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

The description names a specific action ('preview or create') and a specific resource ('ROS2RtxLidarHelper publisher' for an MCP RTX LiDAR runtime). It is distinguishable from sibling ROS2 publishers (clock, TF, camera, joint state) because it is explicitly LiDAR-focused. The mention of create_lidar and render_product_path makes the tool's domain concrete, though the runtime naming is somewhat jargon-heavy.

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 provides a clear prerequisite: the LiDAR prim must first be created with create_lidar. It also explains when render_product_path is relevant as an override for externally-created render products. However, it does not state when to choose this tool over sibling ROS2 publisher tools or when preview should be used instead of create, leaving some routing decisions implicit.

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

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

With no annotations, the description carries the full burden of disclosing side effects, but it only states that the tool can preview or create. It does not explain whether creation replaces an existing publisher, registers a persistent workflow, or requires an idempotency key, nor what preview returns; the meaning of '6.0-style' is also left opaque.

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 concise sentence with no filler, which is efficient. However, it is under-specified rather than appropriately concise, relying on unexplained jargon and omitting essential clarifiers that would justify its brevity.

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

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

For a tool with 11 parameters, no annotations, and zero schema coverage, this description is critically incomplete. It does not explain required inputs, optional behavior, return values, or how this integrates with ROS2 workflows, so an agent cannot reliably invoke it correctly.

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

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

Schema description coverage is 0%, so the description was expected to compensate for the schema's silence, but it provides no explanation for any of the 11 parameters. graph_path, target_prims, topic_name, qos_profile, static_publisher, and the other arguments remain completely undocumented.

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

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

The description names a specific action ('Preview or create') and a specific resource ('6.0-style ComputeTransformTree to ROS 2 TF publisher'), which distinguishes it from sibling ROS2 publisher tools like create_ros2_clock_publisher or create_ros2_joint_state_publisher. It loses a point because '6.0-style' is unexplained and the relationship between ComputeTransformTree and the publisher is left vague.

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 about when to use this tool over the many sibling ROS2 workflow tools, nor about when to choose preview versus create mode. No alternatives, conditions, or exclusions are mentioned, leaving the agent without selection criteria.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context by distinguishing 'Preview or create' and by noting the job is 'bounded' and 'manual-trigger,' which implies it will not run automatically. However, it does not clarify side effects of preview vs. create, persistence, or what happens after creation.

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 compact and front-loaded, with the main purpose in the first sentence. The randomizer details are presented in a clear, scannable way without redundant or filler 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?

The tool has 11 parameters, no annotations, and a highly technical randomizer schema; the description only covers part of that complexity. Required parameters like camera_prim_path, frame_count, and annotations are not explained, and the relationship to later start/status/delete SDG job tools 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 schema has 0% property descriptions, so the description must compensate. It meaningfully explains the opaque 'randomizers' parameter by specifying typed records and the accepted 'transform' and 'light' fields. However, other parameters such as 'command_id', 'idempotency_key', 'rt_subframes', and especially 'annotations' remain under-specified.

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 action ('Preview or create') on a concrete resource ('bounded manual-trigger BasicWriter SDG job'), which is clear and informative. It does not explicitly contrast with sibling tools like start_sdg_job, so differentiation is left partly to naming and context.

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

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

No when-to-use or when-not-to-use guidance is provided, and no alternative tools are referenced. The phrase 'manual-trigger' implies the job does not auto-start, but the agent must infer the intended lifecycle relative to start_sdg_job, get_sdg_job_status, and related SDG 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?

No annotations exist, so the description must disclose behavior itself. It does disclose the preview-first option and the read-back after deletion, which are meaningful safety and verification traits. However, it does not state that deletion is permanent or irreversible, nor does it describe side effects on connected graphs, so it only partially carries the behavioral burden.

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; every phrase ('preview', 'one exact', 'deletion read-back') contributes information. It is appropriately sized for the tool's complexity.

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

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

For a destructive tool with no annotations and four undocumented parameters, this is too thin. It omits usage conditions, irreversible-destruction warning, and what happens to dependent graphs; the output schema can cover return shape but not these behavioral prerequisites.

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

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

Schema description coverage is 0%, and the description gives no parameter-level semantics beyond implying graph_path identifies the exact graph and that a preview mode exists. It does not explain command_id or idempotency_key, so the description fails to compensate for the schema's gaps.

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

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

States a specific verb ('delete'), a specific resource ('one exact Action Graph'), and adds two distinct behaviors ('preview' and 'deletion read-back'). The 'one exact' qualifier also separates it from any bulk-delete or pattern-delete operation among siblings.

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 get_action_graph, list_action_graphs, or edit_action_graph; no explanation of when preview=true vs preview=false is appropriate. The only usage signal is the name and the phrase 'preview or delete'.

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

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

With no annotations, the description carries the full safety burden. It usefully discloses that the handle is validated before deletion, which is a meaningful behavioral constraint. However, it does not say whether deletion is permanent/recoverable, what happens on validation failure, or whether the operation is idempotent despite the presence of an idempotency_key parameter.

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

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

The description is a single focused sentence with no filler. The operation, resource scope, and validation requirement are all front-loaded, and every word adds meaning.

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 description is minimally viable for a single-delete tool, especially since an output schema exists to document return values. Still, the optional parameters remain unexplained, and the lack of behavioral detail around idempotency and failure modes leaves meaningful gaps for an agent deciding whether and how to invoke the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that handle is an 'opaque handle' that gets validated, but it says nothing about command_id or idempotency_key, leaving those optional parameters semantically unexplained.

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 clear verb ('Delete'), a specific resource ('one managed artifact'), and adds a distinctive behavior ('after validating its opaque handle'). This separates it from sibling tools like cleanup_artifacts (bulk deletion) and read_artifact/get_artifact_info (read operations).

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 'one managed artifact' implies this is for single-artifact deletion rather than bulk cleanup, but no alternatives are named and no explicit when-to-use or when-not-to-use guidance is given. The usage context is inferred rather than stated.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It states the destructive action and that preview is enabled by default, but it does not explain what preview actually does, whether deletion is permanent or reversible, or what happens to empty groups and related resources. For a destructive tool, these are significant omissions.

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 compact and well-structured: the purpose is front-loaded in the first sentence, and the second sentence adds a relevant behavioral default. There is no fluff or redundancy; every word contributes to the core message.

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

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

Despite an output schema being present, this tool has five parameters, no annotations, and zero schema description coverage. The description fails to address the non-obvious parameters delete_empty_group, idempotency_key, and command_id, and does not clarify preview semantics or prerequisites. For a destructive operation, the definition is incomplete.

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

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

Schema description coverage is 0%, yet the description adds no real parameter meaning beyond what the schema already exposes. 'Preview is enabled by default' merely restates the schema default, while important parameters like delete_empty_group, idempotency_key, and command_id are never explained. The agent cannot determine the format of human_path or the side effects of the other parameters from this description.

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

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

The description uses a specific verb 'Delete' and an explicit resource, 'one MCP-owned human', which clearly distinguishes this from sibling tools like delete_artifact, delete_object, and delete_sdg_job. Scoping to 'one' entity makes the operation's breadth unambiguous. This is a clear, differentiated purpose statement.

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

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

The description provides no guidance on when to use delete_human versus alternatives like list_humans, get_human, or delete_artifact, and gives no preconditions such as needing a valid human_path. The preview-default note implies a safety posture but does not state when disabling preview is appropriate or how to verify the correct target before deletion.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds meaningful detail about Camera/LiDAR-specific verified lifecycle teardown and the ignored post_delete_updates behavior for ordinary prims. However, it does not clarify permanence, cascading effects on child prims, or what 'verified teardown' actually entails, leaving some important behavioral aspects vague.

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 compact and front-loaded with the core action, followed by concise argument notes. There is minor redundancy between the opening 'Camera/LiDAR use verified lifecycle teardown' and the post_delete_updates explanation, but overall it is appropriately sized and skimmable.

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 delete-by-prim-path tool, the description covers the required parameter and the one behaviorally important optional parameter. Yet it omits any context around command_id and idempotency_key, does not explicitly route the agent away from sibling delete tools, and could clarify destructive scope. Since an output schema exists, return-value documentation is not required, but the remaining gaps keep this from being fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does document prim_path and post_delete_updates with meaningful semantics, including the 1-240 range and the ordinary-prim caveat. However, command_id and idempotency_key are left entirely unexplained in both the schema and description, which is a clear gap for two of the four parameters.

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 action ('Delete an object') and identifies the target via 'prim_path', making it clear this operates on scene prims. It is not a tautology, but it does not explicitly distinguish itself from sibling delete tools such as delete_artifact or delete_human; the reader must infer the intended domain from 'prim_path'.

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 some usage context by explaining that Camera/LiDAR objects use verified lifecycle teardown and that post_delete_updates is ignored for ordinary prims. However, it does not explicitly state when to use this tool instead of alternatives like delete_artifact, delete_human, or clear_scene, so the selection guidance 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?

With no annotations, the description carries the full burden. It does disclose two important behaviors: preview/delete duality and refusal of foreign graphs. However, for a destructive tool it does not mention irreversibility, what happens when preview is false, how ownership is determined, or any side effects.

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 compact sentence with the core action front-loaded and a key constraint in the second clause. It is economical and scannable, though its brevity comes at the cost of useful parameter and usage detail.

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

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

The description covers enough for a basic call: identify an MCP-owned ROS 2 workflow by graph_path and rely on the preview default. But with no annotations, the meaning of command_id and idempotency_key, the actual deletion behavior, and the definition of MCP-owned remain unexplained. The output schema helps with return values, not with these 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 0%, and the description barely compensates. It loosely maps to 'preview' via 'Preview or delete' and to 'graph_path' via 'workflow', but 'command_id' and 'idempotency_key' get no explanation at all. An agent must guess their meaning from names and defaults.

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

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

The description clearly states the action ('Preview or delete') and the resource ('one MCP-owned ROS 2 workflow'), and adds the scope constraint that foreign graphs are refused. This distinguishes it from the many action-graph and artifact deletion siblings. However, 'MCP-owned' is not defined, which leaves some ambiguity.

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 usage: preview before deleting and only for MCP-owned ROS 2 workflows, with foreign graphs refused. It does not explicitly name sibling tools for discovery (e.g., list_ros2_workflows) or state when not to use it. Guidance is present but only implicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the operation can preview deletion and optionally delete artifacts, but it does not state irreversibility, prerequisites for terminal jobs, or side effects on dependent data. For a destructive tool, this is minimal disclosure.

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

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

The description is a single, front-loaded sentence with no filler or redundant wording. It compresses the core action compactly, though combining 'Preview or delete' into one phrase is slightly dense.

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 5-parameter destructive tool with no annotations and 0% schema coverage, this description is too thin. It omits the preview default behavior, the terminal-job prerequisite, artifact deletion semantics, and idempotency key purpose. The output schema helps with return shape but does not compensate for these 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 0%, and the description does not explain any of the five parameters. 'Optionally its artifacts' loosely hints at delete_artifacts, but preview, command_id, idempotency_key, and their relationships are completely unexplained. An agent cannot infer parameter meanings from this text.

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

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

The description states a specific action ('Preview or delete') and a specific resource ('one terminal job record'), making the core purpose clear. It does not explicitly differentiate from siblings like cancel_sdg_job or cleanup_artifacts, but 'terminal job record' narrows the scope meaningfully.

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 'terminal job record' implies the job should be in a completed/terminal state, but the description gives no explicit when-to-use guidance or alternatives. It does not mention that cancel_sdg_job is for active jobs or that delete_artifact/cleanup_artifacts handle artifacts separately.

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

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

With no annotations, the description carries the full burden. It discloses that deletion is destructive, includes a verification step, and explains the purpose of post_delete_updates for detecting delayed reappearance of prims or render products. It does not discuss permissions or irreversibility, but those are largely implied by 'delete'.

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

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

The description is only a few sentences with zero filler. The primary action is front-loaded, followed by compact parameter explanations. Every sentence contributes useful 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?

For a destructive delete tool with an output schema, the description covers the action, verification behavior, target resource type, and the key tuning parameter. The main gaps are undocumented generic parameters and explicit routing to alternatives, but the core call is well specified.

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

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

Schema description coverage is 0%, so the description must compensate. It meaningfully explains prim_path and post_delete_updates, including the range 1–240 and why updates are needed. However, command_id and idempotency_key are left undocumented, and with zero schema descriptions an agent gets no help on those parameters.

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 concrete action ('Release and delete'), a specific resource ('one Camera or LiDAR'), and a verification step ('then verify it stays absent'). This clearly distinguishes it from generic deleters like delete_object or delete_artifact without needing to open 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?

The phrase 'Managed Camera or LiDAR prim path' implies the tool is intended for managed sensors, but it never explicitly says when to prefer this over delete_object or how to handle non-managed prims. Usage context is implied, not stated as a rule or 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?

No annotations are provided, so the description must carry the full behavioral burden. It mentions that the tool can 'preview or remove,' which signals a potentially destructive operation, but it does not explain whether preview is a dry run, that preview defaults to true, whether removal is reversible, or what consequences removal has on the Action Graph.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core purpose efficiently, though it is too sparse to fully support safe invocation; conciseness itself is good.

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 potentially destructive tool with no annotations and 0% parameter description coverage, the description is incomplete. It does not explain the preview/removal behavior, required parameters, or how it relates to connect_action_graph, leaving an agent with significant gaps for correct and safe invocation.

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

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

The schema has 0% description coverage, so the description must compensate but does not. It does not explain graph_path, source_attr, target_attr, preview, command_id, or idempotency_key. The only added semantic hint is 'one exact connection,' which implies source_attr and target_attr identify a specific edge, but this is far from sufficient.

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 action—'Preview or remove one exact connection'—on a clear resource, an Action Graph. The phrase 'one exact connection' differentiates it from siblings like connect_action_graph (which adds a connection) and delete_action_graph (which removes an entire graph), so an agent can select it confidently.

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 explicit guidance on when to use this tool versus alternatives such as connect_action_graph or delete_action_graph. Usage is only implied by the verb 'remove,' and there are no exclusions, prerequisites, or alternative routings.

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

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. It clearly indicates this mutates an existing graph by setting attribute values and adding connections. It also gives useful detail about value override structure. However, it does not disclose side effects such as whether existing connections are preserved, whether attribute overrides are permanent, or whether any validation or failure modes exist beyond the graph being existing.

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 well-structured and front-loaded: a one-sentence summary, a short usage intent, focused examples for the two main ScriptNode cases, and a compact Args breakdown. Every section contributes practical value, and the examples are directly actionable without excessive verbosity.

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 moderately complex editing tool, the description covers the three graph-specific parameters with structure and examples, includes a default value for graph_path, and provides enough context to edit ScriptNodes. Gaps remain around command_id and idempotency_key semantics, and there is no guidance about when to use connect_action_graph versus this tool. Output schema exists, so return-value documentation is not required.

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

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

Schema description coverage is 0%, so the description must compensate. It does an excellent job for graph_path, values, and connections by providing structured Args documentation, field descriptions, and concrete ScriptNode examples. However, command_id and idempotency_key are not mentioned at all, leaving those two parameters dependent on their self-explanatory names. This is strong but not complete compensation.

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

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

The description clearly states a specific verb and resource: 'Edit an existing OmniGraph Action Graph: set attribute values or add connections.' It clearly distinguishes itself from creation tools like create_action_graph by emphasizing 'already-created graph.' However, it doesn't explicitly disambiguate from the sibling connect_action_graph, which also adds connections, 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?

The description provides clear usage context: 'Use this to update ScriptNode scripts, change attribute values, or add new connections on an already-created graph.' It implies this is for existing graphs, not new ones, but it does not explicitly name when to prefer an alternative like connect_action_graph or create_action_graph. No exclusions or alternative routing 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?

With no annotations provided, the description carries the full weight of behavioral disclosure. It reveals that operations can be both read-only preview and mutating edit, that payloads additionally support load/unload, and that 'every mutation is read back and rolled back on failure.' This is non-obvious and valuable context for an agent deciding whether to invoke the tool.

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

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

The description is two sentences and each sentence earns its place. The first sentence front-loads the primary function, and the second adds critical behavioral details about load/unload and rollback. There is no fluff or redundancy.

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

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

Although an output schema exists, the tool has 8 parameters (3 required) with no schema descriptions and no meaningful parameter guidance in the description. The description omits crucial information about what values the action parameter accepts, how arc_type is defined, and prerequisites or side effects, making it insufficient for an agent to call the tool correctly without additional exploration.

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

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

Schema description coverage is 0%, so the description must compensate for missing parameter explanations, but it does not. The only parameter-related hint is 'Payloads also support load/unload,' which loosely informs arc_type and action, but it leaves 8 parameters including prim_path, asset_path, command_id, and idempotency_key entirely unaddressed.

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: 'Preview or edit a reference/payload arc,' clearly identifying the tool's subject matter. It also adds functional detail about payload load/unload support. It does not explicitly contrast with sibling tools like edit_sublayer or set_variant_selection, but the resource type is distinct enough to disambiguate.

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: whenever a reference/payload arc needs to be previewed or edited, and explicitly mentions that payloads support load/unload. However, it does not name alternative tools or specify exclusions, leaving the agent to infer the exact selection criteria.

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

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

Annotations are absent, so the description carries the behavioral disclosure burden. It adds useful constraints: the operation requires a stopped timeline and uses exact read-back checks, and a preview mode exists. However, side effects, idempotency semantics, and failure behavior are not disclosed, so transparency is partial.

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 dense sentence that front-loads the operation and includes the key constraints without filler. It is concise, though some terminology is packed tightly and could be expanded without becoming 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?

Given six parameters and a mutation operation with idempotency fields, this description leaves too much unspecified: action vocabulary, parameter semantics, prerequisites, and preview workflow. The output schema helps decode return values, not build correct inputs, so the tool is not fully invokable by description alone.

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

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

Schema description coverage is 0%, so the description must compensate. It loosely maps action to preview/add/remove and layer_path to the root-layer subLayer path, but it does not define allowed action values, the index parameter, preview behavior, command_id, or idempotency_key. A caller cannot reliably construct valid arguments from the text alone.

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

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

The description names a specific operation ('Preview or add/remove') and a specific resource ('root-layer subLayer path'), plus distinguishing checks ('stopped-timeline and exact read-back checks'). It is clear about what the tool touches, though it does not explicitly differentiate it from sibling composition tools like edit_composition_arc.

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 tool versus alternatives, no stated preconditions beyond the implied stopped-timeline requirement, and no advice on when to preview versus apply. Usage context must be inferred from the tool name and sibling list.

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