Loading ToolBench
Model Context Protocol (MCP) server for ROS2 — connect Claude, Antigravity, and AI agents to real robots
Server has 16 tools with complete schemas and descriptions. Naming follows verb_noun convention (ping, list_topics, read_topic, publish_topic, get_*, set_*, tune_*, predict_*, etc.). Descriptions are present and contextual (avg ~150 chars), exceeding the 10-char minimum. However, several tools lack parameter descriptions (e.g., publish_topic's 'payload' field has minimal guidance on structure), and output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages visible in tool definitions. Security concerns: publish_topic and set_parameter are WRITE operations but lack permission gates or dry-run patterns. Composition is reasonable (16 focused tools), but some tools combine multiple concerns (e.g., system_diagnostics returns battery, LiDAR, IMU, nodes, could be split). Baseline: avg tool description length 194 chars; this server averages ~140 chars, within acceptable range. 94% of A+ tools have docstrings; this server has 100% tool descriptions but parameter descriptions are inconsistent.
Inspect a specific ROS2 node and find its related topics (exact name match).
Read a live parameter value from a running ROS2 node.
Read current Kp, Ki, Kd gains from a PID controller node, with safety bounds.
Fetch LiDAR, IMU, battery, cmd_vel, and odometry in one parallel call. Faster than calling read_topic five times sequentially.
[WORLD-FIRST] Converts 360° LiDAR pointclouds into a 2D ASCII spatial radar grid directly inside MCP response JSON, allowing text & vision LLMs to 'see' surrounding space.
List all currently running ROS2 nodes with their namespaces.
publish_topic and set_parameter lack permission gates and dry-run patterns. Destructive WRITE operations should support confirmation or permission checks before execution.
Output schemas are not documented. Tools return data but LLMs cannot plan downstream calls without knowing response structure (e.g., what fields does read_topic return? What is the structure of get_robot_snapshot's parallel response?).
publish_topic's 'payload' parameter lacks type definition and structure guidance. Description says 'Message fields as key-value pairs' but does not specify format, required fields, or validation rules. LLMs will guess at structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
List all active ROS2 topics and their message types.
Test the connection to the ROS2 bridge. Returns status and active node count. Call this before any other tool to verify the server is reachable.
[WORLD-FIRST] Pre-simulate robot trajectory (x,y,theta) over time dt_sec in 1000Hz fast-forward simulation (<0.1ms compute) BEFORE sending commands to hardware.
[WORLD-FIRST] Evaluates proposed parameter or velocity commands against dynamic stability bounds, auto-correcting unsafe LLM inputs and returning mathematical proof.
Publish a message to a ROS2 topic. Sandboxed: blocked in READ_ONLY mode; allowlisted in SAFE_WRITE mode.
Read the latest message from a ROS2 topic. Returns the serialized message and data age in milliseconds. For latched topics (/map, /robot_description), set latched=true.
Dynamically update a parameter on a running ROS2 node. Sandboxed — only allowlisted parameters can be modified in SAFE_WRITE mode.
[WORLD-FIRST] Scans multi-namespace ROS2 graph (/drone_1, /rover_2, /arm_3) and aggregates fleet health for multi-robot coordination.
Run a full robot health check. Returns battery level, LiDAR status, IMU health, active node count, and lists of critical issues and warnings. ALWAYS call this first when the user asks 'what's wrong?' or 'is the robot ready?'
Apply new PID gains to a controller node with safety bounds validation. Gains are validated BEFORE reaching hardware — negative gains are rejected. Returns tuning guidance based on control theory.
Error handling is not visible in tool definitions. No recovery guidance, error classification, or actionable error messages documented. Tools should return 'User not found. Try search_users()' not bare error codes.
system_diagnostics combines multiple concerns (battery, LiDAR, IMU, nodes, issues, warnings). Should split into focused tools: get_battery_status, get_lidar_status, get_imu_status, list_critical_issues. Composition violates single-responsibility principle.