Loading ToolBench
Extends MCPForUnity (Coplay) with HurricaneVR tools: inspect grabbables/sockets/hand grabbers, query player and controller state, force-release objects, teleport the player, and control physics interactables (dials, levers, buttons, doors). Uses reflection — no hard compile dependency on HurricaneVR.
Single tool 'hvr_manage' exhibits severe definition quality issues. While the description is exceptionally detailed (2,400+ chars), it violates the 10 - 1024 char guideline by being verbose and mixing multiple action categories without clear separation. The flat parameter schema lacks per-action validation and type constraints. Most critically, the tool combines 20+ distinct actions (get_status, list_grabbables, setup_grabbable, build_grabbable, build_interactable_door, create_hand_pose, teleport, lock_door, etc.) into a single tool, violating the single-responsibility principle. Parameters like 'action' (string, no enum) invite hallucinated action names. Many parameters lack type constraints (e.g., 'axis' accepts free-form strings instead of an enum). No output schema is documented. Error handling and recovery guidance are absent. The tool is functional but poorly structured for LLM reasoning.
Interact with and set up HurricaneVR Framework components. READ actions (Edit + Play): get_status | list_grabbables | list_sockets | list_hand_grabbers | list_interactables | get_player_state. SETUP actions (Edit mode, adds/configures components on a named GO): setup_grabbable | setup_socket | setup_socket_filter | setup_socketable | setup_physics_door | setup_physics_drawer | setup_physics_dial | setup_physics_button | validate_grabbable. BUILD actions (Edit mode, assemble a full prefab asset in one call): build_grabbable (root HVRGrabbable/Rigidbody/HVRTagSocketable/puzzle component, GrabPoints scaffold, nested mesh, and voxel-fitted primitive colliders from a mesh wrapper prefab — the mesh interior is voxelized and boxes/capsule/sphere are grown inside it, then shrink-verified against the triangles so no collider pokes outside the visual mesh) | build_interactable_door (a static Frame + a swinging_door hinge pivot with HVRPhysicsDoor + HVRRotationTracker, ConnectedBody wired to the frame, plus a front_handle grabbable with HVRPhysicsDial joined to the door so pulling the handle swings it open — hinge_position/handle_offset must be supplied, they are not inferred from mesh geometry. The handle's grab point is fully wired (Grabbable, HandPoser, a default doorknob pose, Stationary/ParentHandModel) so the hand actually poses onto it, and the root gets an HVRObjectCollisionDisabler covering the frame and leaf(ves) so their colliders don't jam each other — set double_door=true plus the *_2 params for a second leaf sharing the same frame. Optional handle_mesh_prefab_path nests a knob/lever visual with voxel-fitted colliders instead of a plain box; optional add_audio wires HSP.Audio.Interactables.HingedDoorAudio; optional add_second_handle (+ second_handle_offset, mirrored per-leaf with add_second_handle_2/second_handle_offset_2) builds an independent second handle on the opposite face, matching Door_02 Variant's oracle front_handle+back_handle pattern so the door opens from either side; start_locked (default true) pins the hinge joint fully rigid until a handle is first grabbed via a persistent listener on HVRGrabbable.Grabbed calling HVRPhysicsDoor.Unlock() — stops closely-spaced leaves jittering against each other before the player touches anything). POSE action (Edit mode, bakes a precise HVRHandPose asset for a grab point on a grabbable prefab — places the HVR preview hand, physics-closes the fingers around the prefab's colliders, saves the pose, and wires it into HVRHandPoser): create_hand_pose. RUNTIME actions (Play mode only): get_input_state | force_release | teleport | lock_door | unlock_door.
Single tool combines 20+ distinct actions (get_status, list_grabbables, setup_grabbable, build_grabbable, build_interactable_door, create_hand_pose, teleport, lock_door, etc.). Violates single-responsibility principle. LLMs cannot reason about which action to invoke without trial-and-error.
Parameter 'action' is a free-form string with no enum constraint. LLMs will hallucinate invalid action names. Should be: enum ["get_status", "list_grabbables", "setup_grabbable", "build_grabbable", "build_interactable_door", "create_hand_pose", "get_input_state", "force_release", "teleport", "lock_door", "unlock_door", ...].
Parameter 'axis' accepts free-form strings (description says 'X | Y | Z | NegX | NegY | NegZ') but is not declared as an enum. LLMs may pass invalid values like 'north' or 'up'. Should be: enum ["X", "Y", "Z", "NegX", "NegY", "NegZ"].
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |
No output schema documented. LLMs cannot predict what fields to expect from get_status, list_grabbables, build_grabbable, etc. Each action returns different structures, but none are formally specified.
Tool description exceeds 1024 chars (2,400+), violating guideline. Mixes action categories (READ, SETUP, BUILD, POSE, RUNTIME) without clear separation. LLMs struggle to parse and prioritize. Should split into separate tools or use structured action groups with per-action parameter subsets.