Robotics MCP Server

robot_behavior

Unify robot behavior controls for animation, camera, navigation, and manipulation in one interface, enabling path planning, camera feeds, pose changes, and arm/gripper operations.

Instructions

Robot behavior control portmanteau - Animation, camera, navigation, and manipulation.

PORTMANTEAU PATTERN: Consolidates animation, camera, navigation, and manipulation operations into a single unified tool. This reduces tool explosion while maintaining full functionality across all behavior categories.

CATEGORIES:

animation: Animation and pose control
camera: Camera feed and visual control
navigation: Path planning and navigation
manipulation: Arm and gripper control

ANIMATION ACTIONS:

animate_wheels: Rotate wheels during movement (Scout mecanum wheels)
animate_movement: Play movement animations (walk, turn, etc.)
set_pose: Set robot pose (sitting, standing, etc. for Unitree)
play_animation: Play custom animations
stop_animation: Stop current animation
get_animation_state: Get current animation state

CAMERA ACTIONS:

get_camera_feed: Get live camera feed (physical Scout camera)
get_virtual_camera: Get Unity camera view from robot perspective
set_camera_angle: Adjust camera angle
capture_image: Capture still image
start_streaming: Start video stream
stop_streaming: Stop video stream
get_camera_status: Get camera status and settings

NAVIGATION ACTIONS:

plan_path: Plan path from A to B (A* or RRT)
follow_path: Execute planned path
set_waypoint: Set navigation waypoint
clear_waypoints: Clear waypoint list
get_path_status: Check path execution status
avoid_obstacle: Dynamic obstacle avoidance
get_current_path: Get current path being followed

MANIPULATION ACTIONS:

move_arm: Move arm to target joint positions or end-effector pose
set_joint_positions: Set individual joint positions (dict of joint_name: angle)
set_end_effector_pose: Move end-effector to target pose (position + orientation)
get_arm_state: Get current arm joint positions and end-effector pose
open_gripper: Open gripper fully
close_gripper: Close gripper fully
set_gripper_position: Set gripper position (0.0 = open, 1.0 = closed)
get_gripper_state: Get current gripper position and force feedback
move_to_pose: Move arm to target pose with IK (inverse kinematics)
home_arm: Return arm to home/rest position

Input Schema

TableJSON Schema

Name	Required	Description
`loop`	No	Whether to loop animation.
`pose`	No	Pose name for set_pose.
`action`	Yes	Action to perform (see category-specific actions above).
`arm_id`	No	Arm identifier for multi-arm robots (e.g., "left", "right").
`angle_x`	No	Camera angle X (pitch) in degrees.
`angle_y`	No	Camera angle Y (yaw) in degrees.
`path_id`	No	Path identifier for follow_path or get_path_status.
`category`	Yes	Behavior category: "animation", "camera", or "navigation".
`robot_id`	Yes	Robot identifier (e.g., "scout_01", "vbot_scout_01").
`waypoint`	No	Waypoint position (x, y, z) for set_waypoint.
`stream_url`	No	Stream URL for start_streaming.
`force_limit`	No	Maximum force/torque limit for movement.
`output_path`	No	Output file path for capture_image.
`wheel_speeds`	No	Wheel speeds for animate_wheels.
`goal_position`	No	Goal position (x, y, z) for plan_path.
`animation_name`	No	Animation name for play_animation.
`start_position`	No	Start position (x, y, z) for plan_path.
`animation_speed`	No	Animation speed multiplier.
`joint_positions`	No	Joint positions dict (e.g., {"shoulder": 45.0, "elbow": 90.0}).
`gripper_position`	No	Gripper position (0.0 = open, 1.0 = closed).
`end_effector_pose`	No	End-effector pose dict with position and orientation.
`obstacle_position`	No	Obstacle position (x, y, z) for avoid_obstacle.
`manipulation_speed`	No	Movement speed (0.0-1.0) for arm/gripper motion.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed24 schema fields changedv0.2.1Aug 24, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / action / description

Added value: +"Action to perform (see category-specific actions above)."

addedInput schema / properties / angle_x / description
```
Added value: +"Camera angle X (pitch) in degrees."
```
addedInput schema / properties / angle_y / description
```
Added value: +"Camera angle Y (yaw) in degrees."
```
addedInput schema / properties / animation_name / description
```
Added value: +"Animation name for play_animation."
```
addedInput schema / properties / animation_speed / description
```
Added value: +"Animation speed multiplier."
```

addedInput schema / properties / arm_id / description

Added value: +"Arm identifier for multi-arm robots (e.g., \"left\", \"right\")."

addedInput schema / properties / category / description

Added value: +"Behavior category: \"animation\", \"camera\", or \"navigation\"."

addedInput schema / properties / end_effector_pose / description

Added value: +"End-effector pose dict with position and orientation."

addedInput schema / properties / force_limit / description

Added value: +"Maximum force/torque limit for movement."

addedInput schema / properties / goal_position / description
```
Added value: +"Goal position (x, y, z) for plan_path."
```

addedInput schema / properties / gripper_position / description

Added value: +"Gripper position (0.0 = open, 1.0 = closed)."

addedInput schema / properties / joint_positions / description

Added value: +"Joint positions dict (e.g., {\"shoulder\": 45.0, \"elbow\": 90.0})."

addedInput schema / properties / loop / description
```
Added value: +"Whether to loop animation."
```

addedInput schema / properties / manipulation_speed / description

Added value: +"Movement speed (0.0-1.0) for arm/gripper motion."

addedInput schema / properties / obstacle_position / description

Added value: +"Obstacle position (x, y, z) for avoid_obstacle."

addedInput schema / properties / output_path / description
```
Added value: +"Output file path for capture_image."
```

addedInput schema / properties / path_id / description

Added value: +"Path identifier for follow_path or get_path_status."

addedInput schema / properties / pose / description
```
Added value: +"Pose name for set_pose."
```

addedInput schema / properties / robot_id / description

Added value: +"Robot identifier (e.g., \"scout_01\", \"vbot_scout_01\")."

addedInput schema / properties / start_position / description
```
Added value: +"Start position (x, y, z) for plan_path."
```
addedInput schema / properties / stream_url / description
```
Added value: +"Stream URL for start_streaming."
```

addedInput schema / properties / waypoint / description

Added value: +"Waypoint position (x, y, z) for set_waypoint."

addedInput schema / properties / wheel_speeds / description
```
Added value: +"Wheel speeds for animate_wheels."
```

Addedv1.0.0Jan 4, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. Each action line names the behavior (e.g., 'clear_waypoints: Clear waypoint list', 'stop_streaming: Stop video stream'), which is reasonable transparency. However, it omits expected side effects, safety warnings, preconditions such as plan_path before follow_path, or any explanation of physical robot interactions.

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

Conciseness3/5

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

The description is organized and front-loaded with its purpose, making it easy to scan. That said, the 'PORTMANTEAU PATTERN' section repeats the same category list and the action lists could be shortened since the schema already defines action categories and parameters. It is comprehensive but longer than strictly needed.

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 complexity with 23 parameters and 25+ actions, the description does provide a near-complete catalog of actions and their behavior. The schema has a rich output schema and 100% parameter coverage, so the description does not need to explain parameter values or return types. It is complete enough for an agent to understand the overall scope, though a per-action required-parameter mapping would be even more complete.

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?

The input schema has 100% parameter description coverage, giving each parameter a clear meaning. The description adds significant value by mapping actions like set_target_pose, plan_path, and set_gripper_position to natural-language semantics and validating expectations like 'gripper_position 0.0 = open, 1.0 = closed.' This extra mapping goes beyond the schema descriptions.

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 opens with a clear statement of scope: 'Robot behavior control portmanteau - Animation, camera, navigation, and manipulation.' It then enumerates four concrete categories with a detailed action list, making the tool's purpose immediately recognizable. However, it never explicitly contrasts itself with sibling tools like robot_control or drone_control, so differentiation is implicit rather than stated.

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

Usage Guidelines3/5

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

The description explains that this is a consolidated tool for animation, camera, navigation, and manipulation operations, which implies when it should be used. It does not explicitly state when not to use it or name an alternative tool for a specific task, so the guidance is contextual but not exclusionary.

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