Provides tools for monitoring, debugging, and managing ROS 2 nodes, topics, services, and TF2 frames, enabling AI agents to interact with ROS 2 systems.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ros-mcp list all ros topics"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for ROS 2 that enables GitHub Copilot and other AI agents to interact with ROS 2 systems. This server provides tools for monitoring, debugging, and managing ROS 2 nodes, topics, services, and TF2 frames.
Add the following to .vscode/mcp.json
{
"servers": {
"ros": {
"command": "npx",
"args": ["ros-mcp"]
}
}
}Ensure the server is selected in tools for vs code copilot
You're good to go! try "List active ros topics" to test it out.
list_ros_nodes: List all running ROS 2 nodes with detailed information
get_node_connections: View all topics a node publishes to and subscribes from
get_node_parameters: List parameters for a specific node
set_node_parameter: Modify node parameters at runtime
run_ros_node: Launch a ROS 2 node from a package
run_ros_launch: Execute a launch file
list_ros_topics: List all available topics with optional detailed type information
get_topic_info: Get detailed information about a specific topic
monitor_topic: Subscribe to a topic and collect messages for a specified duration (observational tool with wait capability)
publish_to_topic: Publish messages to a topic
list_ros_services: List all available services
call_service: Call a service with optional parameters
monitor_tf2_frames: Monitor TF2 transform frames and relationships (includes static and dynamic transforms)
generate_ros_graph: Generate dependency graphs showing connections between nodes and topics (supports both text and Graphviz DOT format)
check_ros_system_status: Check overall system health, daemon status, and node/topic/service counts
Related MCP server: Rosbridge MCP Server
ROS 2 (tested with Humble and later)
Node.js 18+
npm or yarn
# Clone or navigate to the repository
cd /path/to/ROS-MCP
# Install dependencies
npm install
# Build the TypeScript
npm run buildWSL might need linking the nvm node to the default node path
sudo ln -s ~/.nvm/versions/node/v24.11.0/bin/node /usr/local/bin/node sudo ln -s ~/.nvm/versions/node/v24.11.0/bin/npm /usr/local/bin/npm
# Direct execution (recommended for MCP integration)
npm start
# Development with ts-node
npm run devConfigure the MCP server in your GitHub Copilot settings:
{
"servers": {
"ros": {
"command": "node",
"args": ["/path/to/ROS-MCP/build/index.js"]
}
}
}Some tools are designed to collect data over time, allowing the agent to wait and observe:
monitor_topic: Waits for 1-30 seconds, collecting messages from a topic. Supports custom message count limits. Perfect for:
Observing sensor data streams
Verifying topic publishing patterns
Debugging message throughput
monitor_tf2_frames: Observes TF2 frame transforms over a specified duration (1-30 seconds)
Tool: monitor_topic
Parameters:
- topic_name: "/sensor_msgs/LaserScan"
- duration_seconds: 5
- message_count: 10This collects up to 10 messages from the LaserScan topic over 5 seconds.
Tool: generate_ros_graph
Parameters:
- output_format: "text" (or "dot" for Graphviz)Returns a visual representation of how nodes and topics are connected.
Tool: check_ros_system_status
Parameters:
- include_diagnostics: trueProvides comprehensive system status including daemon health, active nodes, and services.
The server is built with:
@modelcontextprotocol/sdk: MCP framework for agent communication
Zod: Type-safe parameter validation
Node.js Child Process: Command execution for ROS 2 CLI tools
Command Execution: Each tool executes the corresponding ros2 CLI command
Output Parsing: Results are parsed and formatted for agent consumption
Timeout Handling: Observational tools use configurable timeouts to collect data
Error Handling: Commands that fail gracefully return error messages
This MCP server follows patterns that work well with AI agents:
Blocking Observational Operations: Tools like monitor_topic block for the specified duration, allowing agents to naturally await results
Bounded Time Windows: All monitoring tools have maximum durations (typically 5-30 seconds) to prevent indefinite waits
Progressive Data Collection: Tools collect data incrementally and return results at the end of the observation window
Clear Output Format: Results are structured text that agents can easily parse and reason about
A Copilot agent using this MCP can:
Agent: "What topics are currently being published?"
[Uses: list_ros_topics]
Agent: "Let me observe the /cmd_vel topic for 5 seconds"
[Uses: monitor_topic with topic_name="/cmd_vel", duration_seconds=5]
[Waits 5 seconds for data collection]
Agent: "Here are the velocity commands being sent: [parsed data]"
Agent: "Show me how all nodes are connected"
[Uses: generate_ros_graph with output_format="text"]
Agent: "Let me try publishing a test message to the /cmd_vel topic"
[Uses: publish_to_topic]
Agent: "Let me check if any node is having issues"
[Uses: check_ros_system_status with include_diagnostics=true]Some ROS 2 CLI commands require the ROS 2 environment to be properly sourced
TF2 monitoring requires the tf2_tools package to be installed
The server executes commands in the current environment - ensure ROS 2 is properly installed
Long-running operations may timeout; adjust duration parameters as needed
Integration with ROS 2 bag recording/playback
Parameter server monitoring
Action client/server interface
Live rqt plugin integration
Rviz2 data streaming
Custom message type parsing
CLI
MIT
Contributions welcome! Please ensure all tools handle errors gracefully and include proper parameter validation.
Call a ROS 2 service with optional parameters
| Name | Required | Description | Default |
|---|---|---|---|
| request | No | The request parameters. A dictionary in YAML format | |
| service_name | Yes | The name of the service |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Call a ROS 2 service with optional parameters,' which does not mention side effects, blocking behavior, service availability requirements, or what the response looks like. This is no more informative than the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is efficient, though minimal; it earns its place but lacks elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should explain the return value and any side effects of calling a service. It does not, leaving out important context that is needed for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes both parameters: service_name and request as a YAML dictionary. The description adds only that parameters are optional, which is implied by the schema's required list. This is baseline coverage with no significant extra semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Call') and the resource ('a ROS 2 service'), which differentiates it from sibling tools like list_ros_services or publish_to_topic. The phrase 'with optional parameters' adds a bit of scope, making the purpose specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It only restates what the tool does without explaining the context in which it should be selected over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check overall ROS 2 system status, daemon, and node health
| Name | Required | Description | Default |
|---|---|---|---|
| include_diagnostics | No | Include diagnostic aggregator info |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the high-level purpose but does not mention whether the operation is read-only, what the output looks like, whether a running daemon is required, or any potential side effects. For a monitoring tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and target. It contains no redundant words or filler, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, so the description is adequate for basic invocation. However, it omits the return format or what 'system status' specifically entails, and there is no usage hint, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, include_diagnostics, has a description in the schema ('Include diagnostic aggregator info'). Schema coverage is 100%, so the description adds no further value beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check') and the target ('overall ROS 2 system status, daemon, and node health'). It is not a tautology and gives a specific resource, but does not explicitly differentiate from sibling list tools like list_ros_nodes or monitor_topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, when an aggregate health check is preferable to detailed node/topic inspection, or any exclusions. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate RQT graph showing connections between nodes and topics
| Name | Required | Description | Default |
|---|---|---|---|
| output_format | No | Output format: text (ASCII) or dot (for graphviz) | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the core action without disclosing any behavioral traits such as whether it launches a GUI, writes output files, or has blocking behavior. This is insufficient for a tool with no structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single sentence with no redundant words, efficiently conveying the tool's primary function. It is appropriately front-loaded and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately covers the basic action. However, the absence of behavioral details and usage context leaves gaps, making it minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter output_format is fully documented in the schema with an enum and default, providing complete semantic coverage. The description adds no additional parameter context, but the schema already provides the necessary details, aligning with the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Generate' and identifies the resource as 'RQT graph' showing node-topic connections, making its purpose clear. However, it does not differentiate itself from sibling tools like get_node_connections or list_ros_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for visual graph generation but provides no explicit guidance on when to choose it over alternatives such as get_node_connections or list_ros_nodes. There is no mention of exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all topics that a node publishes to and subscribes from
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | Yes | The name of the node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly indicates a read operation (via 'Get'), but it does not disclose behavior on missing nodes, whether the output includes only active topics, or any permissions required. For a read-only tool, this is acceptable but not rich in behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states what the tool does and is appropriately concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description states the core functionality completely. It lacks details about return format or error behavior, but given the low complexity, the description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers 100% of the parameter (node_name), so baseline is 3. The description adds minimal extra meaning by implying node_name is the subject of the connection query, but it does not provide additional format or constraints beyond the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving all topics a node publishes to and subscribes from. It uses a specific verb ('Get') and resource ('all topics that a node publishes to and subscribes from'), which distinguishes it from sibling tools like get_topic_info or monitor_topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a node's publish/subscribe connections, but it does not explicitly state when to choose this over alternatives, nor does it provide exclusions or prerequisites. The single parameter node_name is straightforward, but guidance on comparisons with other topic-related tools is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get parameters for a specific ROS 2 node
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | Yes | The name of the node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It only states 'Get parameters,' which implies a read operation, but it does not disclose return format, behavior for non-existent nodes, or whether runtime parameters are included. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It effectively conveys the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with full schema coverage and no output schema, the description is sufficient for an agent to know what to provide and what the tool does. It could mention the return format (e.g., a dictionary of parameter names and values), but the lack is not critical given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (node_name) described as 'The name of the node.' The description's reference to 'specific ROS 2 node' aligns with the schema but adds no extra meaning beyond it. Baseline 3 is appropriate since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('parameters for a specific ROS 2 node'), clearly distinguishing it from siblings like set_node_parameter (set) and list_ros_nodes (list nodes). It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific ROS 2 node' implies the tool is for a single node, not for listing all parameters across nodes. However, it does not explicitly mention when to use this tool versus alternatives like set_node_parameter or list_ros_nodes, leaving the usage context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific ROS 2 topic including message type
| Name | Required | Description | Default |
|---|---|---|---|
| topic_name | Yes | The name of the topic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full disclosure burden. It mentions the return includes 'message type' but does not disclose other returned fields, potential errors for non-existent topics, or that it is a read-only operation. The lack of side-effect information and output details leaves the agent under-informed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loaded with the verb and target, with zero filler. Every word contributes meaning, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, no output schema, no annotations), the description is adequate but incomplete regarding the exact set of returned information beyond 'message type' and any system prerequisites. The lack of an output schema increases the need for description clarity, and the minimal detail does not fully satisfy that need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'topic_name' is fully documented in the schema with 'The name of the topic'. The description only repeats that it targets a specific topic, adding no new semantic value beyond the schema. Baseline 3 is appropriate since schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and the resource ('a specific ROS 2 topic'), and adds a distinguishing detail ('including message type') that separates it from sibling list_ros_topics and monitor_topic. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when a specific topic's details are needed) but does not explicitly name alternatives like list_ros_topics for enumeration or monitor_topic for live data. Context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently running ROS 2 nodes and their information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It states the operation is a listing (implying non-destructive), but it does not elaborate on potential latency, dependencies on a running ROS master, or what 'their information' includes. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core action and scope without extraneous words. It is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify what 'information' means (e.g., node names, namespaces, associated topics). The vague 'their information' creates a gap in completeness, though the tool is simple and likely understandable in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. The description adds no parameter-specific detail because none is needed; the baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('all currently running ROS 2 nodes and their information'). It distinguishes itself from siblings like list_ros_topics and get_node_parameters by focusing on nodes rather than topics or parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for checking running nodes, but it does not explicitly mention when to prefer this over siblings such as generate_ros_graph or get_node_connections. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available ROS 2 services
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'list all available' implying a read-only, comprehensive operation, but does not disclose any details about output format, potential side effects, or environmental requirements. For a simple listing tool this is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the action and resource. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description adequately conveys its purpose. It doesn't explain return values, but 'List all available' implies a list of service names, which is clear enough for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain any. The baseline for zero params is 4, and the description does not need to add param-level detail. It remains sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all available') and the resource ('ROS 2 services'), distinguishing it from sibling tools like list_ros_topics and list_ros_nodes. It is a specific verb+resource construction with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives, nor any exclusions. It merely states what it does, leaving the agent to infer usage context from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all ROS 2 topics with their types and publishers/subscribers
| Name | Required | Description | Default |
|---|---|---|---|
| detailed | No | Show detailed topic information |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the tool lists all topics with types and publisher/subscriber counts, which is the core behavior. However, it does not comment on side effects, permissions, or output format, leaving some ambiguity typical of a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the function without any redundant or filler content. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with one optional parameter, the description covers the primary output and scope. There is no output schema, but the description suffices for basic understanding; it lacks explicit mention of behavior with the 'detailed' flag, but that is captured in the parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'detailed' is fully described in the input schema (100% coverage) as a boolean for showing detailed information. The tool description itself adds no additional parameter semantic, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'List' and clearly identifies the resource 'all ROS 2 topics' and what is delivered ('types and publishers/subscribers'). This distinguishes it from sibling tools like list_ros_nodes and list_ros_services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting an overview of topics but provides no explicit when-to-use guidance or contrasts with alternatives like get_topic_info or monitor_topic. The context is clear enough for a simple list tool, but exclusions are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor TF2 transform frames and their relationships
| Name | Required | Description | Default |
|---|---|---|---|
| duration_seconds | No | Duration to monitor TF2 frames |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It vaguely says 'monitor' without indicating whether the tool streams data, blocks, or returns a snapshot, nor what happens to the relationship data. This lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise. However, it is so brief that it omits details addressed in other dimensions, though for conciseness it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a monitoring tool, the description lacks essential context: it does not explain what output to expect, how monitoring is terminated, or how results are presented. The schema covers the duration parameter, but the overall operational behavior is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter duration_seconds is fully described in the schema (including default, bounds, and description), covering 100% of parameter documentation. The tool description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (monitor) and resource (TF2 transform frames and their relationships), which distinguishes it from sibling tools like monitor_topic that target topics. However, it does not explicitly contrast with alternatives, so it falls short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over siblings like monitor_topic or check_ros_system_status. The description only states what it does, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor a ROS 2 topic for a specified duration. Collects messages over time.
| Name | Required | Description | Default |
|---|---|---|---|
| topic_name | Yes | The name of the topic to monitor | |
| message_count | No | Stop after collecting this many messages (whichever comes first) | |
| duration_seconds | No | How long to monitor (max 30 seconds) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'collects messages over time' but does not describe blocking behavior, return format, or the interaction between duration and message_count (e.g., 'whichever comes first' is only in schema). The agent is left guessing about side effects or output expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly states the core action and purpose, and contains no filler. Every word contributes to understanding the tool's function. It is appropriately sized for maximal clarity with minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must itself supply context about behavior and results. It does not mention what happens after the duration ends, what is returned (e.g., collected messages), or the stopping condition based on message_count. Given the tool's moderate complexity, this is a significant gap that leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no parameter-level details beyond what the schema already provides, which matches the baseline of 3 for high coverage. No additional value from the description on this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Monitor a ROS 2 topic for a specified duration.' The verb 'monitor' distinguishes it from siblings like 'publish_to_topic' or 'list_ros_topics', and the phrase 'for a specified duration' sets it apart from one-off queries. This is a specific verb+resource combination with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for observing messages over time with a duration limit, but it does not explicitly state when to use this tool versus alternatives like 'get_topic_info' or 'list_ros_topics'. There are no exclusions or comparator references, leaving the agent to infer context from the tool's name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish a message to a ROS 2 topic
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The message content in ROS message format | |
| topic_name | Yes | The topic name to publish to | |
| topic_type | No | The message type (e.g., std_msgs/String) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action and omits important details like prerequisites (e.g., a running ROS 2 environment), requirement to specify topic_type, behavior if the topic does not exist, or any blocking semantics. This is essentially no transparency beyond the bare act.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is front-loaded with the action and resource, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the one-sentence description is insufficient. It fails to mention important context such as the requirement to specify a topic_type, potential failure modes, or any prerequisites, leaving the agent underinformed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all three parameters (message, topic_name, topic_type), so the baseline is 3. The description itself adds no parameter-level information, but the schema already handles the semantics, so no deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Publish a message to a ROS 2 topic' uses a specific verb ('publish') and resource ('ROS 2 topic'), clearly stating the tool's function. It distinguishes well from sibling tools like call_service (services) and monitor_topic (reading messages).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives such as monitor_topic or call_service. The intended usage is only implied by the verb 'publish', which is sufficient for a clear action but lacks any contextual 'when' or 'why' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch a ROS 2 package launch file
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Additional arguments to pass to the launch file | |
| launch_file | Yes | The launch file name (without .launch.py) | |
| package_name | Yes | The ROS 2 package name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits such as whether launching is blocking, how to stop the process, side effects, or return behavior. The description only says 'Launch' and provides no such details. For a launch tool, these behaviors are nontrivial and should be clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the core function directly and efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a non-trivial operation (launching a launch file). The description does not explain what happens after launch, whether the process runs in background, how to handle long-running launches, or what is returned. This lack of context is a significant gap for a complex operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 3 parameters, so the baseline is 3. The description itself adds no extra parameter context beyond what the schema already gives. The schema descriptions are clear ('without .launch.py'), so there is no loss from the description's brevity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Launch a ROS 2 package launch file'. It clearly identifies the tool's function and distinguishes it from siblings like run_ros_node (which runs a single node) and call_service. The phrase 'ROS 2 package launch file' scopes it precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to launch a ROS 2 launch file, but gives no explicit guidance on when to use it versus alternatives like run_ros_node. Sibling tool names provide context, but the description itself lacks exclusions or when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a ROS 2 node from a package
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Additional arguments for the node | |
| node_name | No | Custom name for the node instance | |
| node_type | Yes | The node executable name | |
| package_name | Yes | The ROS 2 package name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must convey behavioral implications. It merely says 'run', which implies starting a process, but does not disclose that the node may run indefinitely, block execution, or require termination. No information about side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, making it efficient. However, it lacks any supporting structure such as examples or parameter context, which prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that likely launches a long-running process, the description is insufficient. It neither explains the node lifecycle, return behavior, nor the use of parameters. Sibling tools like run_ros_launch are not differentiated, and there is no output schema or annotations to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully documented in the schema (100% coverage), so the description adds no additional parameter semantics. The baseline of 3 applies since the schema handles parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Run' and names the resource 'ROS 2 node from a package', which distinguishes it from sibling tool run_ros_launch. However, it doesn't explicitly contrast with launch-based execution, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this instead of alternatives like run_ros_launch, publish_to_topic, or call_service. The description only states the basic action without any context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a parameter for a ROS 2 node
| Name | Required | Description | Default |
|---|---|---|---|
| node_name | Yes | The name of the node | |
| param_name | Yes | The parameter name | |
| param_value | Yes | The parameter value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects. It only says 'Set a parameter' without noting that this modifies the node's runtime state, may require permissions, or is not persistent across restarts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero redundant words. It is well-structured and front-loads the action clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three simple string parameters and no output schema, the description is minimally sufficient. However, it lacks any mention of behavioral effects or usage context, such as whether the change takes effect immediately or the node must exist, which could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters (node_name, param_name, param_value) with 100% coverage, including their types. The description adds no additional parameter-specific context, so it settles at the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('a parameter for a ROS 2 node'), which distinguishes it from sibling tools like get_node_parameters and publish_to_topic. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It does not mention that get_node_parameters should be used for reading, or that the node must be running.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1call_servicecheck_ros_system_statusgenerate_ros_graphget_node_connectionsget_node_parametersget_topic_infolist_ros_nodeslist_ros_serviceslist_ros_topicsmonitor_tf2_framesmonitor_topicpublish_to_topicrun_ros_launchrun_ros_nodeset_node_parameterEach tool targets a distinct ROS 2 entity (topic, node, service, parameter, tf2, launch). No two tools perform the same action on the same resource; monitor_topic and get_topic_info differ in whether they collect sample messages or describe topic metadata.
All tool names use snake_case and follow a clear verb_noun pattern: list_*, get_*, set_*, run_*, monitor_*, publish_to_*, call_*, generate_*. There are no mixed conventions or ambiguous verbs like 'process' or 'do'.
15 tools is within the sweet spot for a ROS 2 control surface. Each tool addresses a core need: introspection (list, get, monitor), control (run, publish, call), and configuration (set). The count feels appropriate without being bloated.
The set covers the main ROS 2 interaction modes: nodes, topics, services, parameters, TF frames, and launch files. A notable gap is the lack of action support or explicit node shutdown, but these are advanced use cases; the core workflows are well covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/husain-zaidi/ROS-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
