robot-motion-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ROBOT_MOTION_RUNS_ROOT | No | Directory where per-run worktrees and run records are stored. | |
| ROBOT_MOTION_WORKSPACE | No | Workspace directory used for defaults when explicit root variables are not set. | |
| ROBOT_MOTION_AUDIT_ROOT | No | Directory of historical JSON records used for experiment reports. Takes precedence over the workspace defaults. | |
| ROBOT_MOTION_PLANNER_PYTHON | No | Path to a Python interpreter that has the planner's required packages installed. Fixed by configuration and cannot be selected by a model tool argument. | |
| ROBOT_MOTION_NEW_DESIGN_ROOT | No | Directory containing a `New_Design` tree with the planning inputs. Takes precedence over the workspace defaults. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tasksB | List tasks that actually exist in the connected read-only sources (New_Design placement seeds, frozen research-audit tasks, labeled MOCK fixtures). No task ids are invented. |
| get_task_infoA | Read one task's configuration: workpieces, placement/allocation, robots, planner methods, collision-semantics flags (verbatim from config), start/end data sources and data completeness. task_id forms: 'ND-SEED-', frozen research task ids (e.g. 'T1_CM2B'), or 'MOCK-*' fixtures. |
| get_experiment_reportA | Read a frozen experiment/run report with honest status semantics: planner raw status + canonical state, candidate-path facts, independent-validation state (PASSED/FAILED/INCOMPLETE/NOT_VALIDATED/TOOL_ERROR), durations, error class, caveats and source-file references. run_id forms: '/' (e.g. 'rm_next_009_full_motion_generation_cost/T1_CM2B_P0', 'third_workpiece_process_boundary/EXPERIMENT', '_audit/FINAL_QA'), 'ND-SEED-', 'MOCK-*'. Timeouts are never reported as infeasibility. |
| start_motion_planA | Start ONE real offline planning run for a New_Design seed task (task_id 'ND-SEED-') inside an isolated per-run worktree copy; the upstream project is never written (pre/post SHA-256 manifests attached). planner: whitelist ['Lazy_PRM'] (applied to the worktree config). time_budget_seconds: 10-1800 (default 120); on expiry the process tree is killed and status becomes TIMEOUT (never 'no path exists'). request_id (optional, [\w.-]{1,64}) makes retries idempotent. Returns immediately with a run_id; poll get_plan_status. Only one real run at a time. |
| get_plan_statusA | Query a real planning run (run_id from start_motion_plan) with three separate dimensions: execution_status (PENDING/RUNNING/COMPLETED/FAILED/TIMEOUT/UNKNOWN - COMPLETED means the tool finished, not that a path was found), plan_result (PATH_FOUND/NO_CANDIDATE_WITHIN_BUDGET/ERROR/NOT_AVAILABLE) and validation_status. Status survives service restarts via persistent records; unverifiable outcomes are reported as UNKNOWN, never silently converted. |
| validate_motionA | Report the independent-validation status bound to a run's candidate path. For NEW local runs this is NOT_RUN until a scene-compatible strict validator is registered - planning success is never treated as PASS, and historical verdicts are never transferred to new paths. For frozen research-audit records the recorded verdict is reported verbatim, bound to the recorded path sha256 and input contract. run_id forms: local 'R-*' runs and historical records like 'rm_next_015_fr69b_transfer_expansion/Q1_RRT_E1' or '.../REF_T1_CM2B_P0'. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool maps to a distinct action/resource: listing tasks, reading task details, reading frozen experiment reports, starting a planning run, polling run status, and validating a run's path. The frozen-report versus live-run-status split is clearly described and unlikely to be confused.
All tools use snake_case with a clear verb_noun pattern: list_tasks, get_task_info, get_experiment_report, start_motion_plan, get_plan_status, validate_motion. The convention is uniform and predictable.
Six tools is well-scoped for a motion-planning server: task inspection, report reading, run initiation, status polling, and validation are each represented exactly once. There is no redundant or filler tool.
The core lifecycle is covered: discover tasks, inspect them, start a plan, poll status, and validate results. Minor gaps remain, such as canceling/stopping an in-flight planning run or listing available runs/reports directly.