Loading ToolBench
ROS 2 MCP Server bridge for LM Studio and local LLM workflows.
This ROS2 MCP server demonstrates moderate definition quality with significant inconsistencies across tools. Tool naming is reasonably clear and action-oriented (list_*, read_*, call_*, get_*, start_*, cancel_*), following verb-noun conventions. However, descriptions vary widely in quality, some tools like 'list_ros_graph' provide clear context ('List available ROS graph resources by type'), while others lack sufficient detail for LLM decision-making. Input schemas are present for all 10 tools and mostly well-formed with proper type annotations, but parameter descriptions are sparse or generic. Output schemas are completely undocumented, there is no explicit specification of what each tool returns, forcing LLMs to infer structure. Error handling guidance is absent. Several tools (particularly action-related ones like 'call_action', 'start_action') combine concerns or expose low-level parameters (feedback_limit, timeout) without clear guidance on when to use parallel variants. The server lacks security annotations, permission declarations, and audit logging guidance. Overall, this is a functional but unpolished implementation suitable for local ROS2 integration but lacking the refinement needed for production-grade agent deployment.
Call ROS2 action and return final result with sampled feedback.
Call ROS2 service with request payload and timeout in seconds.
Request cancellation for a running action started by start_action.
Get incremental action progress/feedback events.
Get current status for an action started by start_action.
Get publishers/subscribers/services for a node.
List available ROS2 actions (allowlist-filtered).
No output schemas documented for any tool. LLMs cannot infer what fields to expect in responses, breaking composition patterns and forcing agents to guess structure.
Parameter descriptions are generic or missing for critical parameters. E.g., 'Service request payload' for request_data lacks format guidance (JSON structure, required fields, type mappings). 'ROS2 topic name' and 'ROS2 node name' don't specify expected format or provide discovery guidance.
Action tools expose low-level parameters (feedback_limit, timeout with arbitrary defaults of 20 and 60) without explaining the semantic difference between 'call_action' (blocking, synchronous) and 'start_action' + 'get_action_status' (async polling). LLMs cannot decide which pattern to use.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
List available ROS graph resources by type.
Read latest message from topic with timeout in seconds.
Start a ROS2 action in background and return action_id for polling.
No error handling guidance. Descriptions do not explain what errors are retryable, what requires user intervention, or how to recover from timeouts/service calls. No indication of which tools are idempotent.
Security and permission information completely absent. No documentation of which tools require ROS2 permissions, what scopes they represent, or how credentials are managed. 'call_service' and 'call_action' are destructive but lack WRITE/REVERSIBLE risk annotations in descriptions.
'list_actions' takes no parameters and description says it is 'allowlist-filtered', but there is no parameter to control which actions are listed or guidance on discovery. If allowlist is configured server-side, this must be documented.
Tool composition issue: 'read_topic' accepts arbitrary ROS2 topic names as free-form strings without discovery. LLMs have no way to list available topics before calling read_topic. 'list_ros_graph' with type='topic' should be called first, but this dependency is undocumented.
Parameter 'timeout' appears in 6 tools with default=60 (seconds), but descriptions never explain timeout semantics, whether it applies to the ROS2 call or total wall time, or what happens when exceeded (immediate failure vs retry).