MCP server for ABB RobotStudio via Robot Web Services (RWS) and ClaudeBridge Add-In. Provides tools to control RobotStudio application and robot controller via SDK and RWS APIs.
35 tools with consistent naming (verb_noun pattern: rs_*, rws_*) and basic descriptions. However, critical gaps undermine quality: (1) NO input schemas visible for 17/35 tools (rs_ping, rs_get_station, rs_get_station_objects, rs_save_station, rs_get_tasks, rs_controller_status, rs_start_simulation, rs_stop_simulation, rs_pause_simulation, rs_reset_simulation, rs_simulation_status, rs_get_paths, rs_check_collisions, rws_get_controller_state, rws_get_io_signals, rws_get_rapid_variables, rws_get_robot_position), these score 0 on schema. (2) Descriptions are terse (10-80 chars), below the 194-char baseline for A+ tools; many lack context on WHEN to use or WHAT is returned. (3) Parameters present in 18 tools lack descriptions (e.g., rs_get_modules 'task' param has description, but rs_read_module 'task' and 'module' lack full context on format/constraints). (4) No output schemas documented anywhere, LLMs cannot plan downstream calls. (5) Error handling is generic (catch-all err() function) with no recovery guidance. (6) No pagination, limits, or result-capping documented despite tools returning lists (rs_get_station_objects, rs_get_paths, rws_get_io_signals, rws_get_rapid_variables). Naming is solid (90/100), but schema and description quality drag the average down.
Run collision check on station objects
Get controller state via SDK (systemState, runMode, simulation)
Create a new robot path
Create a new robot target at coordinates
List RAPID modules in a task (SDK)
Get targets/waypoints in a path
List all robot paths in the station
17 tools have NO input schema (empty {} or missing zod definition). Affects: rs_ping, rs_get_station, rs_get_station_objects, rs_save_station, rs_get_tasks, rs_controller_status, rs_start_simulation, rs_stop_simulation, rs_pause_simulation, rs_reset_simulation, rs_simulation_status, rs_get_paths, rs_check_collisions, rws_get_controller_state, rws_get_io_signals, rws_get_rapid_variables, rws_get_robot_position, rws_start_rapid, rws_stop_rapid, rws_reset_rapid.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 48 | 2026-07-28+ | v2 |
Get active RobotStudio station info (name, controllers)
List all objects in the station (robots, tools, smart components)
List RAPID tasks with module counts (SDK)
Pause RobotStudio simulation
Check if RobotStudio ClaudeBridge Add-In is running and connected
Read controller config file (SYS.cfg, EIO.cfg, SIO.cfg, MOC.cfg)
Read full RAPID source code of a module (SDK)
Read a RAPID variable initial value (SDK)
Reset simulation to start position
Save the active station to disk
Set simulation speed multiplier
Get simulation state and time
Start RobotStudio simulation (Play)
Stop RobotStudio simulation
Write controller config file
Write RAPID module source code into running controller (SDK)
Set a RAPID variable initial value (SDK)
Get controller state (running, stopped, etc.) via RWS
List all I/O signals on the controller via RWS
List RAPID variables on the controller via RWS
Get current robot TCP position and joint angles via RWS
Read a single I/O signal value via RWS
Read a RAPID variable value via RWS
Reset RAPID program to start via RWS
Start RAPID program execution via RWS
Stop RAPID program execution via RWS
Write a single I/O signal value via RWS
Write a RAPID variable value via RWS
No output schemas documented for any tool. LLMs cannot infer what fields to expect (e.g., does rs_get_station return {name, controllers} or {id, name, controllers, metadata}?). Prevents downstream tool chaining and forces agents to guess field names.
Descriptions are terse (10 - 80 chars, well below 194-char baseline). Most lack WHEN to use, WHAT is returned, or prerequisites. E.g., 'Get active RobotStudio station info (name, controllers)' is 50 chars but omits: Is this the currently open station? What if no station is open? What does the response structure look like?
Generic error handling via catch-all err() function returns 'Error: <message>' with no recovery guidance. Per pattern:recovery-guide, errors should tell LLMs what to do next. E.g., 'Cannot connect to ClaudeBridge at http://localhost:58080. Is RobotStudio running? Check ABB_BRIDGE_URL env var.' instead of raw exception text.
List-returning tools (rs_get_station_objects, rs_get_paths, rs_get_path_targets, rws_get_io_signals, rws_get_rapid_variables) have no pagination, limit, or result-capping documented. Per pattern:paginated-result, large result sets blow context windows. No limit parameter or total_count in response.