create_robot

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

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

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

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

Well-structured and appropriately sized. The purpose and key fuzzy-matching behavior come first, prerequisites are one line each, and the return-value explanation is concise. Every sentence carries useful information; no filler.

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

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

Given no annotations and moderate parameter complexity, the description covers the essential workflow: pre-conditions, fuzzy matching, parameter meanings, and return fields for immediate chaining. The output schema exists, so detailed return-value documentation is not required. The main gap is undocumented command_id and idempotency_key parameters and no explicit alternative-tool routing.

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

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

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

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

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

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

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

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

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

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