Skip to main content
Glama
sandraschi

Robotics MCP Server

by sandraschi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

vbot_crud

Manage virtual robots across Unity, VRChat, and Resonite with full CRUD operations—create, read, update, delete, and list robot instances.

Instructions

CRUD operations for virtual robots (vbots).

This tool provides complete lifecycle management for virtual robots:

  • Create: Spawn and register a new virtual robot

  • Read: Get details of an existing virtual robot

  • Update: Modify virtual robot properties (scale, position, metadata, etc.)

  • Delete: Remove and unregister a virtual robot

  • List: List all virtual robots with optional filtering

Supported robot types:

  • "scout": Moorebot Scout (mecanum wheels, indoor)

  • "scout_e": Moorebot Scout E (tracked, waterproof, outdoor)

  • "go2": Unitree Go2 (quadruped)

  • "g1": Unitree G1 (humanoid with arms)

  • "yahboom": Yahboom ROSMASTER series (AI-enabled wheeled robots)

  • "drone": Generic PX4/ArduPilot drones

  • "px4_quad": PX4 quadcopter drones

  • "ardupilot": ArduPilot-based drones

  • "robbie": Robbie from Forbidden Planet (classic sci-fi robot)

  • "custom": Custom robot type (requires model_path)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scaleNoSize multiplier for "create" or "update" (e.g., 1.0 = original size).
metadataNoAdditional metadata dictionary for "create" or "update".
platformNoTarget platform ("unity" or "vrchat"). Default: "unity".unity
positionNoSpawn/update position (x, y, z) for "create" or "update".
robot_idNoVirtual robot identifier (required for "read", "update", "delete"). Auto-generated for "create" if not provided.
operationYesCRUD operation to perform: - "create": Create/spawn a new virtual robot - "read": Read/get details of an existing virtual robot - "update": Update properties of an existing virtual robot - "delete": Delete/remove a virtual robot - "list": List all virtual robots (optionally filtered)
model_pathNoPath to 3D model file (.glb, .fbx, .vrm) for "create" with "custom" robot_type.
robot_typeNoType of robot (required for "create", optional for "list"). Must be one of: "scout", "scout_e", "go2", "g1", "yahboom", "drone", "px4_quad", "ardupilot", "robbie", "custom".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.2.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / metadata / description
      Added value: +"Additional metadata dictionary for \"create\" or \"update\"."
    • addedInput schema / properties / model_path / description
      Added value: +"Path to 3D model file (.glb, .fbx, .vrm) for \"create\" with \"custom\" robot_type."
    • addedInput schema / properties / operation / description
      Added value: +"CRUD operation to perform:\n- \"create\": Create/spawn a new virtual robot\n- \"read\": Read/get details of an existing virtual robot\n- \"update\": Update properties of an existing virtual robot\n- \"delete\": Delete/remove a virtual robot\n- \"list\": List all virtual robots (optionally filtered)"
    • addedInput schema / properties / platform / description
      Added value: +"Target platform (\"unity\" or \"vrchat\"). Default: \"unity\"."
    • changedInput schema / properties / platform / enum
      Previous value: -[
-  "unity",
-  "vrchat"
-]New value: +[
+  "unity",
+  "vrchat",
+  "resonite"
+]
    • addedInput schema / properties / position / description
      Added value: +"Spawn/update position (x, y, z) for \"create\" or \"update\"."
    • addedInput schema / properties / robot_id / description
      Added value: +"Virtual robot identifier (required for \"read\", \"update\", \"delete\").\nAuto-generated for \"create\" if not provided."
    • addedInput schema / properties / robot_type / description
      Added value: +"Type of robot (required for \"create\", optional for \"list\").\nMust be one of: \"scout\", \"scout_e\", \"go2\", \"g1\", \"yahboom\", \"drone\", \"px4_quad\", \"ardupilot\", \"robbie\", \"custom\"."
    • addedInput schema / properties / scale / description
      Added value: +"Size multiplier for \"create\" or \"update\" (e.g., 1.0 = original size)."
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

There are no annotations, so the description carries the burden of explaining side effects. It does this reasonably well by saying 'spawn and register' for create and 'remove and unregister' for delete, and by listing supported robot types. It does not cover permission requirements, persistence guarantees, or failure behavior, but the destructive lifecycle side effects are disclosed.

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

Conciseness4/5

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

The structure is clear and scannable: a lead sentence, a CRUD operation bullet list, then a supported-robot-types list. The 'complete lifecycle management' phrase slightly restates CRUD, but helps emphasize the tool's purpose. Overall the description is informative without being excessive.

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

Completeness4/5

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

Given the 8 parameters, the operation enum, and the output schema, the description is nearly complete: it explains operations, side effects, and the robot-type semantics that are most likely to confuse an agent. The main gaps are explicit exclusion of non-lifecycle vbot tools and some detail on what 'optional filtering' means for list, but those are also covered by the schema.

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

Parameters4/5

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

Schema description coverage is already 100%, so the baseline is 3. The description adds meaningful semantic context beyond the schema by grouping scale/position/metadata with create/update, noting that custom robots require a model_path, and explaining what each robot type actually is, such as mecanum wheels or waterproof tracked outdoor.

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

Purpose4/5

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

The description clearly identifies the resource (virtual robots/vbots) and the general action ('CRUD operations'), then enumerates create/read/update/delete/list. It is specific enough to distinguish this from control or manufacturing tools, though it could more explicitly differentiate from sibling tools such as robot_control or robot_virtual.

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

Usage Guidelines3/5

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

The description implies usage: if you need lifecycle management or a CRUD action on a vbot, this is the tool. However, it does not explicitly state when to avoid it, nor does it point to alternatives for non-lifecycle tasks like real-time control, manufacturing, or behavior definition.

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

Deploy Server

Other Tools