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

No annotations provided; description does not disclose behavioral traits such as reversibility, side effects, or required permissions beyond the fact that it modifies 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 concise (two sentences plus parameter docs) and front-loaded with the primary action. No unnecessary words.

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

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

Given the tool is simple (2 required params) and an output schema exists, the description covers the core action but omits usage context and behavioral details.

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 0% schema coverage, the description adds basic meaning for both parameters ('Prim path of the material', 'Prim path of the object'), but no format or examples.

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 'Bind a material to an object' with specific arguments, effectively distinguishing it from siblings like 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?

No guidance on when to use this tool versus alternatives, nor any prerequisites or caveats. Implied usage only.

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

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

With no annotations, the description carries full burden. It discloses that it captures an RGB image and returns metadata if output_path is not set. However, it does not mention any destructive or side effects, permissions, or constraints (e.g., camera must exist). Some useful behavior is stated, but lacking depth.

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 brief, with a clear first sentence explaining purpose, followed by a compact argument list. No redundant information. Every sentence adds value.

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

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

For a simple tool with two optional parameters and an output schema (though not shown), the description covers the essential behavior: capturing an image and saving to file or returning metadata. It does not explain metadata contents or output schema details, but the presence of an output schema partially mitigates that. Overall, fairly 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 explains both parameters: prim_path as the camera's prim path and output_path as the file path to save the image, adding meaning beyond the schema. However, it omits details like file format or valid values. Overall, good but not exhaustive.

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 ('capture'), resource ('RGB image from a camera sensor'), and the primary arguments. It distinguishes itself from sibling tools like 'create_camera' or 'get_scene_info' by focusing on image acquisition. The scope is well-defined.

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 (when an image from a camera is needed) but does not explicitly state when not to use or provide comparisons to alternative tools like 'get_scene_info'. No context-sensitive guidance is given.

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

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

With no annotations, the description carries the full burden, and it delivers: it discloses destructive scope, the side effect on the environment's collision floor, the interaction with create_physics_scene, and the defaultLight retention policy with a clear rationale. This covers exactly the non-obvious behaviors an agent needs to anticipate.

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 longer than necessary in places, but every paragraph adds distinct information: core action, environment/physics side effects, lighting rationale, and parameter meanings. The main sentence is front-loaded, and the Args section is clearly structured.

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 destructive tool has no annotations, two optional flags, and cross-tool implications with load_environment and create_physics_scene. The description addresses all of these, explains the defaultLight exception, and gives enough context for correct invocation. With an output schema present, no return-value discussion is needed.

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

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

Schema coverage is 0%, and the schema only provides titles and defaults, so the description must compensate. It explains both keep_physics and keep_environment in plain language and adds a practical cost rationale for keep_environment, which is precisely the semantic value the schema lacks.

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 line, 'Remove all prims from the scene,' states a specific verb and resource and clearly distinguishes this from sibling tools like delete_object, which targets individual prims. The description then sharpens scope by explaining interactions with the loaded environment and the always-kept defaultLight.

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 practical guidance on when to use keep_environment ('Reloading one costs seconds, so pass this when clearing objects between attempts') and warns about downstream consequences for create_physics_scene. It does not explicitly name alternatives like delete_object for removing a single prim, but the context is clear.

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

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

No annotations provided, so the description carries full burden. It does not disclose important behaviors like whether cloning is a deep copy, what happens if target_path exists, or error handling.

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: a single sentence stating the purpose, followed by a clearly structured parameter list with no fluff.

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

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

Covers basic input semantics well but lacks information about output (though output schema exists), error conditions, and side effects like overwriting 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?

With 0% schema description coverage, the description adds clear, meaningful explanations for all three parameters, including an example for position.

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 (duplicate) and resource (existing object to a new prim path), distinguishing it from sibling tools like create_object and transform_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 description implies usage for copying objects but lacks explicit guidance on when to use versus alternatives 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 full burden, and it does so thoroughly. It discloses the underlying og.Controller.edit() mechanism, automatic node creation/wiring for shortcuts, the usePath/scriptPath side effects, and explains evaluator behavior, e.g., push evaluates every application update even when the simulation is stopped.

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?

Although long, it is tightly organized with Args and two examples, and every section adds operational value. The repeated reload guidance is minor redundancy, not bloat, given how important that choice is.

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 complete for a tool of this complexity: it covers all parameters, gives usage examples, explains tradeoffs, references sibling tools like reload_script and edit_action_graph, and the output schema is present to cover return values.

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: every one of the seven parameters is documented with defaults, expected formats, and concrete examples. It even gives exact attribute path syntax for connections and values.

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 and wire an OmniGraph Action Graph.' It clarifies this is the programmatic equivalent of building one in the visual editor and differentiates from editing by saying it builds the complete graph, reinforced by the later reference to edit_action_graph.

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 when-to-use guidance: script_file is 'RECOMMENDED for anything you will iterate on', inline_script is 'For small, static graphs', and it states that inline edits need edit_action_graph. It also notes that nodes and connections are ignored when script_file is set, preventing misuse.

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 must disclose behavior on its own. It reveals that cameras look down local -Z, that rotation is ignored if target is given, and that the response echoes the applied rotation and aimed_at point. This goes beyond basic schema and helps the agent anticipate outcomes. It does not mention side effects or permissions, but for a creation tool this is sufficient.

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: a one-line purpose, a usage tip, and an Args list. The most critical guidance (prefer target over rotation) is front-loaded. It is somewhat long but every sentence earns its place given the tool's complexity. No fluff.

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 (aiming, multiple parameters, response echo) and lack of annotations, the description covers the essential aspects thoroughly. An output schema exists, so return format details are not needed here. It does not mention error conditions or edge cases, but those are minor for a creation tool.

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

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

Schema description coverage is 0%, so the description must fully compensate. It explains each parameter's meaning, units, defaults, and interactions – e.g., rotation is in degrees and ignored if target is given, target needs a position, resolution defaults to 1280x720. This is exemplary and provides all necessary semantic context.

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

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

The description opens with 'Add a camera sensor to the scene', which is a specific verb and resource. It is clearly distinct from sibling tools like create_light or create_lidar, so an agent can immediately understand what this tool does without inspecting 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 description explicitly advises 'Prefer target= over rotation= for aiming' and explains the reason, plus states that rotation is ignored when target is given. This gives clear guidance on when to use each parameter. It does not directly contrast with sibling creation tools, but the usage context within the tool is well covered.

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

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

No annotations are provided, and the description omits behavioral details such as whether existing prims at the same path are overwritten, required permissions, or side effects. The return value is not mentioned despite an output schema 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 concise and well-structured with an Args block. Every sentence adds value, though the example config could be more specific.

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 4 parameters and an output schema (not shown), the description adequately covers parameters but lacks information on config options and return value, leaving room for ambiguity in tool usage.

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 meaning by explaining the rotation unit (degrees) and providing an example config name, partially compensating for the 0% schema coverage. However, it does not list valid config values or clarify the expected array length for position/rotation.

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 ('Add a lidar sensor') and the resource ('to the scene'), which distinguishes it from sibling creation tools like create_camera or create_light.

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

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

The description provides no guidance on when to use this tool over alternatives (e.g., create_camera), nor does it mention prerequisites or context-specific recommendations.

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

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

No annotations provided, so description carries full burden. It does not disclose side effects (e.g., whether it replaces existing lights at same path), mutability, or system behavior. Only lists params but no behavioral context.

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

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

Description is short and to the point, listing args in a clean format. Could be slightly more concise by removing 'Args:' header, but it's well-structured.

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

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

Adequate for a simple creation tool with output schema. Missing context about uniqueness constraints (prim_path), range limits for intensity/color, and error scenarios. Not critical but could be improved.

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?

All 6 parameters are briefly described with format hints (e.g., '[x, y, z]', '0-1', 'degrees', 'Auto-generated'). This adds meaning beyond the schema, which has 0% description coverage and only 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 it creates a light, with specific verb 'Create' and resource 'light'. It distinguishes from sibling 'modify_light' by implying creation vs modification.

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

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

No explicit guidance on when to use this tool vs alternatives like modify_light or other siblings. Only implicit that it's for creating new lights, but no when-not 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. It discloses a critical behavioral trap: material_path is an alias for prim_path, and an unknown argument is silently dropped, which previously caused failures. This is exactly the kind of behavioral context that helps an agent avoid a real bug. It doesn't mention side effects or return values, but the output schema exists and the warning is high-value.

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

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

The description is well-structured with a clear opening line and a bulleted Args list. The material_path warning is a bit long but earns its place because it documents a silent-failure trap. Slightly verbose in the warning, but every sentence adds value.

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

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

For a 6-param tool with 0% schema coverage and no annotations, the description covers the key semantics: material type, path behavior, and PBR-only params. The output schema exists, so return values are covered elsewhere. Missing explicit guidance on what happens when material_type is 'physics' (which params are ignored) is a minor gap, but the description is largely 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 explains material_type values, prim_path auto-generation, the material_path alias trap, and the PBR-only scope of color/roughness/metallic. This adds meaning beyond the raw schema, though it doesn't give exact value ranges for all params (color range is given, roughness/metallic are not).

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 ('PBR or physics material'), and distinguishes the two material types. It also names the sibling tool apply_material, which helps differentiate this creation tool from the application tool.

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

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

The description explains when to use this tool (creating materials) and gives a clear warning about the material_path alias pitfall, which is valuable usage guidance. It doesn't explicitly list alternatives or when-not-to-use, but the context is clear enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the full behavioral burden and meets it: it discloses the non-obvious scale convention (raw multiplier of native size), gives native sizes, and states precedence when both scale and size are provided. It also discloses differing return behavior for geometric prims vs Plane: prim_path/actual_size/bounding_box vs prim_path only.

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

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

The description is front-loaded with the core action and the critical size/scale warning before the Args list. It is long but organized into clear prose and an Args reference, with almost no filler; the repetition of scale caveats is useful emphasis rather than 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 8 optional parameters, no schema-level descriptions, and no annotations, the description is complete enough to call correctly: it supplies defaults, explains precedence, enumerates supported object types, and describes return fields. The output schema may carry the formal return structure, but the prose adds the needed 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?

Schema description coverage is 0%, so the description must compensate, and it does: every parameter is documented with units or value ranges, including object_type normalization, position as world coordinates, rotation in degrees, color 0-1, and the crucial scale/size distinction. This far exceeds the bare schema 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 opens with a direct verb and resource: 'Create a primitive object (Cube, Sphere, Cylinder, Cone, Capsule, Plane).' The enumerated types make the scope unmistakable and separate it from sibling creation tools like create_robot, create_camera, and generate_3d.

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

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

It gives explicit when-to-use guidance for the key parameter choice: 'Prefer `size` for absolute sizing' and 'Use `scale` only for deliberate non-uniform shaping; otherwise use `size`.' It doesn't name sibling tools for non-primitive creation, but the primitive type list and the size-vs-scale rule provide clear usage context.

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

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

No annotations are present, so the description carries the full burden. It discloses the conditional creation of a ground plane, the response fields ground_plane and ground_plane_created, the risk of duplicate floors, and the limitation with Mesh floors. This goes beyond a simple action statement and reveals side effects and edge cases.

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 well-structured. It front-loads the purpose, then gives usage guidance, then behavioral details, then parameter explanations. Each sentence contributes to understanding the tool's behavior and edge cases. While verbose, the complexity of the tool justifies the length; it is not redundant.

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

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

The tool has an output schema, so return values are covered. The description covers the key preconditions (get_scene_info, load_environment ordering), the conditional behavior, the response fields, and the risks. An agent has all necessary information to call this tool correctly and interpret results. No critical gaps remain.

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

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

Schema coverage is 0%, so the description must explain parameters. It provides an 'Args' section defining gravity as a vector and scene_name as the prim name, but omits the default value for gravity (standard gravity is vague) and does not explicitly state that both parameters are optional, though the schema shows defaults. It adds meaning beyond the schema but could be more precise.

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 physics scene' and immediately clarifies the conditional ground-plane logic, which is unique to this tool. It clearly distinguishes this from sibling creation tools like create_object or create_material by focusing on physics scene setup and the environment interaction.

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

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

Explicitly instructs to call get_scene_info first to verify connection, and explains the ordering requirement relative to load_environment. It states the consequence of calling this tool before load_environment (two collision floors) and warns about Mesh floors not being recognized. This provides clear when-to-use and precautionary 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?

Discloses fuzzy matching, return fields, and prim_path override behavior. With no annotations, description carries the burden and does well, though could mention if conflicting robots are replaced.

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

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

Two clear sentences for purpose, then bullet-style parameter details. Front-loaded with core purpose and prerequisites. No superfluous 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?

Given the tool's moderate complexity (4 params, fuzzy matching, overrides) and presence of an output schema, the description covers prerequisites, fuzzy matching behavior, and return fields adequately for correct usage.

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 0% schema description coverage, the description provides meaningful explanations for all 4 parameters: robot_type as a fuzzy search term, position as world coordinates, name as custom prim name, and prim_path as an override. Adds value beyond schema types.

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

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

The description clearly states the tool creates a robot in the scene from the Isaac Sim asset library, with specific verb+resource. It distinguishes from siblings like create_object and import_urdf via the robot library source.

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

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

Explicitly advises calling list_available_robots first and creating a physics scene before use, providing clear context. Does not explicitly state when not to use, but guidance is sufficient.

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

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

The description does not disclose any behavioral traits beyond 'delete', such as irreversibility, cascade effects, or permissions. No annotations are provided to compensate.

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 very concise and front-loaded, but it could be more informative without adding much length.

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

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

Given the tool's destructive nature and lack of annotations, the description should provide more context about return values, error handling, or effects on the scene.

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

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

The description explains that prim_path is 'the prim path of the object to delete', adding context beyond the schema's type definition, but the information is minimal.

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 ('object from the scene'), clearly differentiating it from sibling tools like clone_object 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?

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or conditions for 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?

No annotations provided, and description doesn't mention error conditions, permissions, or side effects beyond the stated editing capabilities.

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

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

Well-structured with paragraphs and bullet points, front-loads purpose but could be slightly more concise.

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

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

Covers essential aspects for a complex tool with optional parameters, but could discuss return values or error handling more explicitly.

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 0% schema description coverage, the description thoroughly explains each parameter with examples, adding significant meaning beyond the schema.

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

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

The description clearly states it edits an existing OmniGraph Action Graph by setting attribute values or adding connections, which is specific and distinguishes from siblings like create_action_graph.

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 detailed examples for ScriptNode updates and parameter documentation, but doesn't explicitly state when not to use or compare with alternatives beyond creation.

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

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

With no annotations, the description carries full responsibility for disclosing side effects. It explicitly warns that touching an articulation controlled by a running ScriptNode/Action Graph can silently break its control path, that read-only diagnostics are safe, and that stop_simulation should be used before writes. This is strong, actionable risk 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 detailed but every block earns its place: purpose, routing, caution, escalation path, and parameter semantics. The structure uses clear labels and scannable lists, and the front-loaded 'Escape hatch' phrase immediately conveys the tool's nature.

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 arbitrary-code natureaint and the existing output schema, the description covers everything an agent needs: when to use it, when not to, safety hazards, the stopping prerequisite, and the alternative for persistent code. No critical context appears missing.

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

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

Schema description coverage is 0%, so the description alone carries parameter meaning. It explains that 'code' is Python code executed in the Isaac Sim context and that 'cwd' is an optional working directory added to sys.path. This goes well beyond the raw schema 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 opens with 'Escape hatch: execute arbitrary Python code in Isaac Sim,' using a specific verb and resource. It clearly distinguishes itself from named sibling tools by listing what those tools handle and framing this as the fallback for uncovered 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 description gives explicit 'PREFER named tools over this' and 'USE this for' sections, naming specific alternatives like set_joint_positions, get_prim_info, and step_simulation. It also provides a concrete boundary: use reload_script for persistent controllers over 20 lines.

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

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

With no annotations, the description carries full responsibility for behavioral transparency. It fails to disclose important behavioral traits such as expected latency, asynchronous behavior, resource requirements, or side effects. The mention of 'Beaver3D' hints at an external service but lacks detail.

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 relatively concise, consisting of a single sentence followed by a list of parameters. However, the parameter list largely duplicates information already in the input schema, and could be integrated more efficiently. The structure is functional but not optimized.

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 complexity of a 3D generation tool, the description is incomplete. It does not discuss required inputs (e.g., one of text_prompt or image_url must be provided), output behavior, or limitations. The presence of an output schema may compensate for return value documentation, but the description still lacks key 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?

Despite 0% schema description coverage, the description provides basic parameter explanations: 'Text description for 3D generation.' and 'URL of an image for 3D generation.' etc. While this adds meaning beyond parameter names, the descriptions are minimal and do not specify constraints like coordinate system for position or the requirement that one of text or image must be provided.

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 it generates a 3D model from text or image using Beaver3D and loads it into the scene. The verb 'generate' and specific resource '3D model' along with the tool name make the purpose unambiguous. It also implicitly distinguishes from siblings as no other sibling tool generates 3D content.

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 this tool versus alternatives, nor does it mention prerequisites or conditions. It simply describes what the tool does without any usage context 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 provided, the description carries the full burden and does so thoroughly. It discloses what is captured, what may not appear, the non-destructive default, the scoping behavior, and the side effect of clear=True. This gives the agent an accurate behavioral model beyond the raw schema.

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

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

The description is well-organized and front-loaded with the core purpose. The capture scope, limitation, defaults, and parameter explanations each earn their place with no filler. The Args section is concise and directly actionable.

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 is simple, has no required parameters, and includes an output schema, so the description does not need to explain return values. It covers operational context, behavioral caveats, and all parameter semantics. Nothing essential is missing 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?

Input schema has 0% description coverage, so the description must explain the parameters, and it does. Each parameter is documented with its effect, default, and how it changes behavior. This fully compensates for the schema gap.

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

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

The description opens with a clear statement that this is a diagnostic tool for recent WARN/ERROR logs plus captured print() output. It names the specific log sources (carb.log_*/omni.log) and distinguishes captured stdout contexts. This is unambiguous and sufficiently distinct from all sibling 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 provides clear usage context: it is for viewing logs from execute_script / reload_script and current-run activity, with agent-friendly defaults. It explains how to see the full buffer via since_last_play=False and that clear=True is destructive. It does not explicitly name alternatives, but no sibling tool overlaps with log retrieval.

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 fully does so by explaining the return data, the units (per-radian vs per-meter, and the USD per-degree conversion warning), and the fact that it's a diagnostic tool (implying read-only). The explicit warning about the 57.3x stiffness error is a significant behavioral detail that prevents silent failures. No contradictions with annotations (since none exist).

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

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

The description is well-structured and every sentence serves a purpose. It opens with a one-line definition, lists the returned fields, then gives three 'call when' conditions, followed by a crucial units caveat and the parameter explanation. There is no fluff or redundant content; it is appropriately detailed without being verbose.

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 simplicity (one parameter) and the presence of an output schema (which presumably defines the return structure), the description is complete. It covers what the tool does, when to use it, the units, and the parameter semantics. Nothing an agent needs to invoke it correctly is missing. The diagnostic nature and read-only implication are clear, making this a fully self-sufficient description.

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

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

The input schema has one parameter (prim_path) with no description in the schema (coverage 0%). The tool description compensates fully by stating it is the 'USD path to the robot articulation root.' This is sufficient for a single, self-explanatory parameter, and the description adds the necessary context 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 clearly states the tool's function: a diagnostic tool that retrieves joint drive configuration (stiffness, damping, limits, target vs actual positions, position error) for a robot articulation. It uses a specific verb and resource, making it distinct from sibling tools like get_joint_positions or set_joint_positions. The diagnostic focus and explicit return values leave no ambiguity about purpose.

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 explicit, scenario-based guidance for when to use this tool: when joint drives aren't tracking targets, when joints oscillate or are unstable, and when joints hit limits unexpectedly. It also gives a practical caveat about writing gains back via execute_script, which helps agents avoid misuse. This is clear and actionable, distinguishing it from alternatives.

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

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

No annotations are provided, so the description carries full burden. It explains units and joint order, but does not explicitly state that the operation is read-only or has no side effects. The name implies reading, but more explicit behavioral context would improve transparency.

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 four concise sentences plus an Args line, each serving a purpose: purpose, units/order, alternative, and parameter description. No wasted words.

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

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

Given the tool's simplicity (one parameter) and presence of an output schema (not shown but indicated), the description covers the essential aspects: purpose, units, joint order, and recommended alternative. Could be considered complete, though a clear read-only statement would enhance completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It briefly describes prim_path as 'The prim path of the robot.' but does not elaborate on format, constraints, or how to obtain it. Minimal added value over the schema.

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

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

The description clearly states 'Read current joint positions from a robot.', specifying a verb (Read) and resource (joint positions). It adds units and joint order details, and distinguishes itself from the sibling tool step_simulation with observe_joints.

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 explicitly provides an alternative: 'For a combined step-and-read, prefer step_simulation with observe_joints.' This guides when to use this tool vs. a sibling, though it lacks explicit 'when not to use' beyond that.

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 it excels: it explains the timing-dependent nature of RTX lidar data, the meaning of empty reads, the default summary behavior, the large size of raw clouds, and that output_path writes an .npy file readable as an (N, 3) array. This goes well beyond the minimum.

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 with the most critical caveat (timeline playing, sweep timing) before parameter details. Every sentence adds value, and the Args section maps cleanly to the schema without unnecessary 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 description fully covers prerequisites, common failure semantics, output modes, and parameter behavior. Since an output schema exists, detailed return-shape documentation is unnecessary, and nothing critical an agent needs to call the tool correctly appears missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. Each parameter gets meaningful semantics: prim_path identifies the lidar sensor, max_points controls sampled points at even stride and can be omitted for summary-only, and output_path writes the complete cloud and returns a loadable path.

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 'Get point cloud data from a lidar sensor', a specific verb plus resource, and clearly distinguishes itself from siblings like create_lidar and capture_image. It further clarifies that the tool can return either a summary or raw points, leaving no ambiguity about its purpose.

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 clear context for when to use the tool: the timeline must be playing, a sweep only completes on some frames, and an empty read means 'not this frame'. It also advises when to prefer the summary over raw points, though it does not explicitly name alternative tools or exclusion conditions.

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

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

With no annotations, the description carries the full behavioral burden and does so well. It discloses the mass-only-with-MassAPI caveat, velocity units, and the important timing behavior that velocities are zero until the simulation advances. These are non-obvious traits that an agent must know to interpret results correctly.

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-organized and front-loaded: purpose, return contents, unit caveats, timing caveat, then a bulleted call-when list. Every sentence adds value, and the structure makes the information 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?

The description is complete for a single-parameter diagnostic getter. It covers what is returned, key edge cases, units, timing, and when to invoke the tool. Since an output schema exists, not detailing every return field is acceptable.

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, but the description compensates with an Args line: 'USD path to the prim to inspect.' This adds domain meaning beyond the raw parameter name and type, though it could have been slightly richer with path format details or an example.

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: 'Diagnostic tool: get physics state for a prim.' It enumerates the returned data (rigid body status, velocities, kinematic flag, collision info), which distinguishes it from broader sibling tools like get_simulation_state and get_scene_info.

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 explicit when-to-use conditions ('Objects fall through the ground', 'Objects don't move when expected', 'Grasping fails'), which is strong practical guidance. It does not name alternative tools or state when not to use it, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden — and it delivers richly. It discloses the dual-frame convention (position_local vs position_world), the source semantics ('usd' vs 'physics'), the position_warning caveat on Newton, the rotation ordering (XYZ degrees, matching transform_object), local vs world scaling, and the actual_size behavior for geometric prims. This is far beyond the minimum and leaves the agent with no dangerous assumptions about output semantics.

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 longer than average, but every sentence earns its place — the framing notes prevent real errors (bare 'position' confusion, wrong reference frame, spawn-pose misreads). It is front-loaded with the purpose, uses a scannable bullet layout, and avoids fluff. It is verbose by necessity, not by 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?

An output schema exists, so return-value structure need not be spelled out — yet the description goes further and explains the semantics of the returned fields (frame meanings, source values, warning conditions, unit conventions). For a single-parameter read tool this is essentially complete; the only minor omission is error behavior for invalid prim paths, which is not critical here.

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. The single parameter prim_path is given meaning beyond the schema title: 'The USD prim path to inspect,' which clarifies the expected path format. For a one-parameter read tool this is adequate compensation; it could add examples of valid path forms (e.g., /World/Franka/fr3_hand_tcp), but the coverage gap is small since there is only one simple parameter.

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

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

States a specific verb+resource ('Get detailed information about a specific prim') and lists exactly what is returned: type, children, transform block. The explicit 'there is no bare position' note preempts a common agent mistake and differentiates this read tool from siblings like get_robot_info, get_scene_info, and get_simulation_state. An agent can tell what this tool does and what it is not without opening another 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?

Provides explicit usage context ('Use position_world to reason about distances, reach, or contact') and one concrete routing to a sibling ('read it through get_physics_state instead' for the Newton spawn-pose warning case). It also references transform_object's convention to tie related tools together. It does not, however, broadly contrast with the many other read siblings (get_scene_info, get_simulation_state, get_robot_info), so the exclusion guidance is present but not comprehensive.

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. It discloses that the tool returns joint names ordered by DOF index, joint types, and limits with units, which is useful behavioral context. However, it doesn't mention whether this is a read-only operation, whether it requires a valid robot prim, or what happens if the prim path is invalid. The return format is partially covered by the output schema, so a 3 is appropriate.

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, followed by usage timing and return details. The Args section is minimal but acceptable. It earns its place with no wasted words, though the return details could be slightly more structured.

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

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

Given the tool has an output schema and only one parameter, the description is mostly complete. It explains what the tool returns, when to call it, and the meaning of the parameter. It doesn't mention error cases or prerequisites beyond the create_robot hint, but for a simple read-only info tool, this is adequate.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that prim_path is 'The prim path of the robot', which adds minimal meaning beyond the schema's title. It doesn't clarify what a valid prim path looks like, how to obtain one, or whether it should point to a robot root or a specific link. The description adds some context but not enough to fully compensate for the lack of schema descriptions.

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 ('Get'), a specific resource ('robot joint information'), and enumerates the exact content returned (names, DOF count, joint types, limits). It also distinguishes itself from siblings like get_joint_positions and get_joint_config by focusing on kinematic structure rather than state or configuration.

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 explicitly says to call this after create_robot to understand the robot's kinematic structure, which gives clear usage context. It doesn't explicitly name alternatives or exclusions, but the timing guidance and the focus on kinematic structure imply when it is appropriate relative to siblings like get_joint_positions.

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

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

No annotations are present, so the description must carry the full burden. The tool 'pings' and 'returns' information, implying a read-only operation without side effects, but it does not explicitly state that it is non-destructive or clarify what happens if the server is unreachable. The description is adequate but not comprehensive.

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

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

The description is a single clear sentence, front-loading the main purpose and listing key return values. No superfluous words; every part earns its place.

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

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

Given the tool's simplicity (no parameters) and the existence of an output schema (flagged as true), the description sufficiently covers the tool's function. It lists the expected return fields, which is enough for an agent to understand what information is retrieved.

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

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

The tool has zero parameters, and schema description coverage is 100% (trivially). Since no parameters exist, the description needs to add no additional meaning. The baseline score of 4 is appropriate as no compensation is required.

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 'pings the Isaac Sim extension server' and 'returns scene information including stage path, assets root, and prim count.' The verb 'ping' and 'return' with specific resources make the purpose unambiguous, and it distinguishes from sibling tools like get_prim_info which focus on individual prims.

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

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

No guidance is provided on when to use this tool versus alternatives. With many sibling tools (e.g., get_prim_info, get_simulation_state), the agent would benefit from explicit context on when scene-level info is appropriate, but the description omits this entirely.

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. It states what data is returned but does not explicitly confirm the operation is read-only or free of side effects. The 'Get' verb implies a read, but given the zero annotation coverage, more explicit disclosure (e.g., 'does not modify simulation state') would be beneficial. The extra note about step_simulation is about a sibling tool's behavior, not this tool's.

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

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

Two concise sentences. The first front-loads the purpose and return fields; the second adds a useful but tangential warning about step_simulation. It is appropriately sized with no redundant 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?

For a parameterless getter with an output schema, the description sufficiently names the returned fields and even includes a relevant workflow caveat about stepping without playing. No important calling context is missing.

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

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

There are zero parameters and the input schema is empty, so the description cannot add parameter meaning. Baseline 4 applies for no 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?

Description explicitly states the tool retrieves the current simulation state and enumerates the specific components: timeline status, simulation time, and physics dt. It uses a clear verb ('Get') and resource. While it doesn't contrast with sibling get_physics_state, the specificity makes the purpose unmistakable.

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

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

The description provides a specific workflow hint about step_simulation not requiring a running timeline, which indirectly helps an agent decide not to call play_simulation before stepping. However, it does not explicitly state when to use this tool over alternatives like get_physics_state or get_scene_info, nor provide general 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?

No annotations provided, and description does not disclose behavioral traits such as side effects, error handling, or whether the operation is reversible. The description is purely operational.

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, with a clear purpose statement followed by parameter documentation. The Args section is formatted as a docstring, which is efficient but slightly verbose for a tool description.

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

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

Given no annotations and an output schema (true), the description covers core functionality but lacks details about failure modes, default behavior, or interaction with the scene. It is adequate but not comprehensive.

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%, but the description includes an Args section that explains each parameter: 'urdf_path: Path to the URDF file.', 'prim_path: Prim path for the imported robot.', 'position: [x, y, z] world position.' This adds meaning beyond the schema's titles.

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

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

Description clearly states 'Import a robot from a URDF file into the scene.' It uses a specific verb ('import') and resource ('robot from URDF file'), distinguishing it from sibling tools like create_robot or load_usd.

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

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

No guidance on when to use this tool versus alternatives like create_robot or load_usd. Lacks context about prerequisites or conditions.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the list is auto-discovered at startup and reflects actual assets, implying no side effects. This is transparent for a read-only listing tool.

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

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

Three short sentences with no redundancy. The first sentence states the core purpose, the second lists return values, and the third provides context. Every sentence earns its place.

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

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

Given the simplicity of the tool and the presence of an output schema, the description provides sufficient detail about the purpose, return content, and behavior. It is complete for a listing 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?

The tool has zero parameters, and the description adds value by detailing what information is returned (keys, descriptions, manufacturers, asset paths), which goes beyond the empty schema.

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

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

The description clearly states the verb 'List' and the resource 'available robots', and specifies the return fields. It distinguishes from sibling tools like 'create_robot' and 'get_robot_info' by focusing on discovery and listing.

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 context on when to use the tool (after startup) and the source of data (auto-discovered from Isaac Sim asset server). It lacks explicit when-not or alternatives, but the tool's behavior is straightforward.

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, and the description does not disclose behavioral traits such as read-only nature, rate limits, or authorization needs. For a read-like operation, more detail is expected.

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

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

Two concise sentences with no wasted words. Every sentence adds value: scope and examples.

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 parameters and the existence of an output schema, the description is fairly complete. It explains what the tool returns and gives examples. However, it could mention whether the list is limited or if there is any pagination.

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

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

There are zero parameters, so baseline is 4. The description adds clear meaning by specifying the content and source of the list, which is 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 clearly states it lists all available environments from the Isaac Sim asset server, with examples of types (warehouses, offices, outdoor scenes). This strongly distinguishes it from sibling tools like 'load_environment' and 'list_available_robots'.

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 listing environments but does not explicitly provide when-to-use or when-not-to-use guidance. It does not mention alternatives 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 delivers: default one-level depth, the response echo of recursive to prevent false confidence, and the nuanced behavior that non-matching prims are still descended into during recursive filtered searches. It is a read-only listing tool and these semantics are clearly disclosed.

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

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

The one-sentence summary is front-loaded and the paragraphs build useful context, but the explanation is slightly verbose. All content earns its place, so it remains strong despite being beyond a minimal summary.

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

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

Given an output schema exists and no annotations are present, the description covers the important operational semantics: default depth, filtering, recursive behavior, and a use case. Minor gaps such as absolute path expectations or cost warnings for deep recursion are not stated, but the core calling context is complete.

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

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

Schema description coverage is 0%, so the description must explain every parameter; it does. Each arg gets meaningful semantics: root_path is the starting point, prim_type is exemplified with 'Mesh'/'Xform' and its recursive descent behavior, and recursive defines subtree walking.

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-resource pair: 'List the prims directly under root_path, optionally filtered by type.' It immediately clarifies the depth scope, distinguishing this from broader scene inspection tools like search_usd and get_scene_info.

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

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

It gives explicit situational guidance: recursive=True 'is the one you want when checking whether something was really deleted, or when hunting a prim nested under a robot.' It does not explicitly route to sibling alternatives for other cases, so it misses the full when-versus-alternatives 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 the full burden, and it does so thoroughly. It discloses fuzzy matching, automatic Y-up/centimeter corrections, response fields like 'corrections' and 'floor_height_source', fallback behavior, and how prim_path affects scene organization and clear_scene removal.

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 sentence adds actionable information. It is front-loaded with the purpose and prerequisite, then logically organizes caveats about corrections and floor height so an agent can place objects correctly without re-reading the output schema.

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

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

Given two parameters, no annotations, and a complex output, the description covers prerequisites, naming, fuzzy matching, coordinate-system corrections, placement semantics, and response interpretation. An agent has everything needed to invoke the tool and interpret the result 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?

The input schema has 0% description coverage, but the description fully compensates. It defines environment as a name or fuzzy search term with examples, and prim_path with its default, behavioral implications, and relationship to clear_scene.

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: 'Load a pre-built environment into the scene.' It clarifies this is distinct from arbitrary USD loading by calling it 'pre-built' and directing users to list_environments, effectively differentiating it from siblings like load_usd.

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 says to call list_environments first, providing a clear prerequisite and workflow. It also explains when prim_path defaults are desirable, but it does not explicitly discuss when to choose an alternative such as load_usd or when not to use this tool.

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

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

No annotations provided, so the description carries full burden. It discloses the action (load into scene) but does not cover behavioral traits such as whether it is destructive, merges, or requires an existing stage. Lacks details on return value or error handling.

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 moderately concise with a clear docstring format. The Args section repeats schema info but adds context. Could be shortened slightly, but overall efficient.

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

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

Given the simple tool function (loading an asset) and presence of an output schema, the description is adequate but has gaps: does not specify behavior when file is missing or prim_path exists. More completeness could include error conditions or return value hints.

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 0% schema description coverage, the description adds meaning beyond parameter names: 'usd_url' explained as URL or path, 'prim_path' as prim path, 'position' as world coordinates, 'scale' as scale factors. This significantly aids understanding.

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 (Load), resource (USD asset), and source (URL or file path). It distinguishes from sibling tools like 'import_urdf' and 'load_environment'.

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

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

No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or conditions. It is implied for loading USD assets but lacks explicit context.

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

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

No annotations provided, and the description lacks behavioral details such as error handling (e.g., if prim_path is invalid), side effects, or permission requirements. The description only states 'modify properties' without further elaboration.

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: a single purpose line followed by clear argument definitions. It avoids unnecessary words, but the docstring format is slightly verbose for a tool description.

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

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

Given the simplicity of the tool and presence of an output schema (though not shown), the description covers basic functionality. However, it omits error cases and preconditions, which are important for contextual completeness.

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

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

With 0% schema description coverage, the description adds meaning for intensity ('New intensity value') and color ('[r, g, b] new light color (0-1)'), clarifying format and range. However, prim_path is not explained, leaving some ambiguity.

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 'Modify properties of an existing light,' specifying the verb and resource. It distinguishes from siblings like create_light and delete_object. However, it could be more explicit about which properties are modifiable beyond the listed parameters.

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

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

No guidance on when to use this tool versus alternatives like create_light or transform_object. No context about prerequisites (e.g., light must already exist) 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 carries the full burden of disclosing behavioral traits. It merely states the action without mentioning side effects, reversibility, safety, or impact on simulation state. This is insufficient for an agent to understand the implications of pausing.

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, consisting of a single sentence that is front-loaded with the action. No words are 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?

The description covers the basic action but omits important context such as preconditions (e.g., the simulation must be running) or behavioral details. An output schema exists, so return values are handled, but the description could still be more complete for an agent to use it safely.

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

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

The tool has no parameters, and the schema coverage is 100% (trivially). The description adds no parameter information because none is needed. Per guidelines, zero parameters warrant a baseline score of 4.

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 'pause' and the resource 'physics simulation', making the tool's purpose immediately understandable. It is distinct from siblings like 'play_simulation' and 'stop_simulation', though it does not explicitly differentiate between pause and stop.

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 usage guidelines are provided. The description does not indicate when to use this tool over similar siblings like 'stop_simulation' or 'step_simulation', nor does it mention any prerequisites or context for use.

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

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

No annotations provided; description does not disclose side effects, error conditions, or behavior if already running.

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

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

Single sentence, no wasted words. However, it could be slightly expanded without losing conciseness.

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

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

For a simple parameterless tool, description covers the basic action but lacks context about simulation state or output.

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

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

No parameters exist, so baseline 4 applies. Description adds minimal meaning beyond schema, but schema has no properties.

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 'Start the physics simulation' clearly states the action and object. It distinguishes from siblings like pause_simulation but does not specify if it resets or resumes.

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 versus other simulation controls (e.g., step_simulation) or prerequisites like having a scene loaded.

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

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

No annotations provided, so description carries full burden. 'Force re-scan' implies mutation but does not disclose side effects, permissions, or safety. Lacks detail for a mutating operation.

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

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

Two concise sentences, front-loaded purpose and usage. No wasted words.

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

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

For a parameterless tool with output schema, description covers purpose and trigger condition completely.

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?

Tool has 0 parameters with 100% schema coverage. Description adds no parameter info, but none is needed. Baseline 4 applies.

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

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

The description clearly states the verb 'force re-scan' and the resource 'asset server for available robots'. It distinguishes from sibling 'list_available_robots' by indicating it triggers an update.

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

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

Explicitly states when to use: 'if new robot assets were added'. Does not mention when not to use or alternatives, 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?

With no annotations at all, the description fully carries the behavioral burden. It discloses automatic mode selection, force-recompilation of ScriptNodes, standalone re-execution, sys.path modification, and the silent dropping of unknown arguments. These are important non-obvious behaviors beyond the schema.

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

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

The description is well structured with a clear opening, mode explanation, workflow list, and argument details. Every section earns its place, and the most important information is front-loaded. Length is justified by the tool's dual-mode 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?

Given the tool's dual-mode nature, absence of annotations, and 0% schema description coverage, the description covers everything needed: when it applies, how it behaves, required workflow context, and parameter semantics. The presence of an output schema means return-value documentation is not required here.

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%, but the description compensates fully. It explains file_path, script_file as an alias, module_name's optional role, and even the reason both aliases are accepted. This is more useful than typical 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 begins with a specific verb and object: 'Reload a Python controller from a file on disk.' It then clearly separates two modes, making it easy to distinguish from siblings like execute_script and create_action_graph. The mention of ScriptNode recompilation gives precise resource 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?

The description explicitly states when each mode applies and provides a workflow linking reload_script to create_action_graph, step_simulation, and play_simulation. It also references execute_script as the alternative for standalone execution, giving an agent clear decision criteria.

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

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

No annotations provided. Description lacks behavioral details such as side effects, whether the asset is fully loaded or referenced, or any prerequisites.

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?

Concise: one-line purpose followed by a well-structured args block. Every sentence provides essential information without 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?

Covers purpose and parameters adequately, but lacks description of return values/output schema, failure behavior, or how the asset integrates into the scene.

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

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

No schema descriptions (0% coverage), but the args block in description adds meaning: e.g., 'position: [x,y,z] world position' clarifies format and purpose beyond parameter 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?

Description clearly states verb 'Search...then load' and resource 'NVIDIA USD asset library', distinguishing it from sibling tools like load_usd which loads specific files.

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?

Implied usage for text-based asset search with auto-loading, but no explicit guidance on when not to use or comparison to alternatives like load_usd or create_object.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool operates via ArticulationAction, uses specific units (radians/meters), and interacts with other tools. However, it does not mention potential errors (e.g., out-of-range joints) or side effects beyond setting positions. Still, it provides sufficient behavioral context for a simulation tool.

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

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

The description is concise and well-structured, with clear sections for units, usage, and arguments. It front-loads the main action and provides essential details without unnecessary verbosity. Minor redundancy (e.g., mentioning 'joint positions' twice) but overall efficient.

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 that an output schema exists, the description does not need to cover return values. It adequately covers purpose, prerequisites, parameter behavior, and post-conditions. Some details about error handling or validation are missing, but the description is sufficiently complete for effective tool usage.

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 prim_path as the robot's prim path, joint_positions as a list of target values, and joint_indices as optional for selecting specific joints. It adds meaning by specifying units and prerequisites (use get_robot_info). While not exhaustive, it adds significant value beyond the schema.

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

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

The description clearly states the tool's purpose: 'Set target joint positions on a robot via ArticulationAction.' It specifies the action (set), resource (joint positions), and mechanism (ArticulationAction). This distinguishes it from sibling tools like get_joint_positions and step_simulation.

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 explicit usage guidelines: it instructs users to first call get_robot_info to discover joint names, types, and limits, and after setting positions, to use step_simulation to advance and observe results. It also warns against using play_simulation with sleep. This clearly defines when and how to use the tool.

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 must disclose behavioral traits. It implies mutation but does not clarify persistence, required simulation state, or whether other parameters are affected. Minimal transparency beyond parameter listings.

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 with a purpose statement followed by a structured argument list. No wasted words, though a brief note on return value or behavior would enhance completeness.

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 simplicity and presence of an output schema, the description covers parameter semantics but omits behavioral context like whether the call is synchronous or requires a running simulation. Adequate but with 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%, so the description compensates by explaining each parameter: gravity as a vector [x,y,z], time_step in seconds, gpu_enabled as enabling GPU acceleration. This adds value beyond the schema's type info.

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

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

The description states 'Configure physics engine parameters,' which is a clear verb+resource pair. It distinguishes from sibling tools like 'get_physics_state' (read) but does not explicitly differentiate from other configuration tools.

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

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

No guidance on when to use this tool versus alternatives, prerequisites, or side effects. The description only states what it does without context for appropriate invocation.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does well: it discloses exact frame counting, self-contained initialization on first call, operation only on paused/stopped timelines, and error behavior on a playing timeline. It stops short of describing post-step timeline state or what happens when no observe arguments are provided, but the disclosed behavior is already 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 longer than average, but nearly every sentence earns its place: core behavior is front-loaded, the play_simulation exclusion is critical, and the debug loop is a practical aid. It is slightly extended by the numbered workflow, but the structure keeps it readable and purpose-driven.

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 potential for confusion with play_simulation, pause_simulation, and stop_simulation, this description is functionally complete. It explains all three parameters, the exact behavioral contract, error conditions, and a recommended debug workflow; return-value details are covered by the output schema, so nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains num_steps as 'Number of simulation frames to step,' observe_prims as prim paths returning position and velocity, and observe_joints as articulation prim paths returning joint positions. This adds real semantic value beyond the raw parameter 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 opens with a precise verb and resource: 'Advance the simulation by exactly N physics frames on a FROZEN timeline.' It also distinguishes itself from play_simulation by explicitly framing step as the frozen-timeline counterpart, so an agent can select it correctly without inferring from the 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?

The description gives explicit when-to-use and when-not-to-use guidance: do NOT call play_simulation before or during the debug loop, step errors if the timeline is playing, and play_simulation is reserved for final continuous runs. The included debug loop further demonstrates the intended sequencing with sibling tools like set_joint_positions and get_physics_state.

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 transparently explains that articulations and rigid bodies reset to their spawn pose, and provides a familiar reference (Isaac UI Stop button). It doesn't mention whether non-rigid-body objects (e.g., lights, cameras) are affected, which is a minor gap, but the core behavior is clear.

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

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

Two concise sentences with no wasted words. The primary action and side effect are front-loaded, and the when-to-use guidance is integrated naturally. Perfectly structured for quick parsing.

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

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

For a parameterless tool with an output schema (per context signals), the description fully covers what it does and when to use it. No missing information that an agent would need to call it correctly.

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

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

The tool has zero parameters, so the description needs no parameter explanation. Baseline of 4 is appropriate; the description adds no parameter-specific information because none is needed.

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

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

States a specific verb ('Stop'), resource ('physics simulation'), and the key side effect ('reset to spawn state'). The description clearly distinguishes this from siblings like pause_simulation by emphasizing the reset behavior. An agent can tell exactly what this tool does without 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?

Explicitly says 'Call this to return the scene to a clean starting point before another run', giving a clear context. It doesn't name alternatives like pause_simulation, but the reset semantics implicitly differentiate it from a simple pause. The guidance is adequate but could be improved by noting when not to use it (e.g., when you want to preserve current state).

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 full burden for behavioral disclosure. It states 'set' implying mutation but lacks details on side effects, permissions, or constraints such as whether the transform is absolute or relative.

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 with a one-line summary followed by an Args section. It is well-structured and front-loaded, though the Args section adds minimal extra value over the schema.

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

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

Given the moderate complexity of a transform setter and the presence of an output schema (not shown but indicated), the description adequately covers the purpose and parameters. No gaps in understanding the operation.

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

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

The description includes a docstring-style explanation for all four parameters, adding meaning beyond the schema (e.g., 'world position', 'degrees', 'scale factors'). Since schema coverage is 0%, this compensation is valuable, though the descriptions are brief.

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 'Set the transform (position, rotation, scale) of an existing object,' using a specific verb and resource. This distinguishes it from sibling tools like create_object or delete_object, which have 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention when not to use it or suggest other tools for related operations like reading transforms.

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