Which integrations are available for this server?

Allows creation and management of ROS 2 development projects, including workspaces, packages, nodes, launch files, parameter files, and tests.

How do I use ros2_dev_mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ros2_dev_mcp Create a new ROS 2 package named my_package in workspace demo_ws" 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.

ros2_dev_mcp

by vagotec

Overview Schema Related Servers Score Discussions

Python

Local

Phase 1 - Safe ROS 2 Project Creation

Goal

Phase 1 establishes the development-focused ros2_dev_mcp server and provides controlled ROS 2 project creation through MCP.

The main goal is to allow an MCP-compatible client such as Codex to create ROS 2 development projects without giving the client unrestricted filesystem or shell access.

This phase also establishes the architectural separation between ROS 2 runtime operations and ROS 2 development operations.

Runtime operations belong to:

ros2_mcp

Development operations belong to:

ros2_dev_mcp

Generated and managed ROS 2 workspaces are stored separately below:

~/projects/robotics/mcp_workspaces/

The result is a clear separation:

~/projects/robotics/
├── ros2_mcp/          # ROS 2 runtime MCP server
├── ros2_dev_mcp/      # ROS 2 development MCP server
├── mcp_workspaces/    # MCP-managed ROS 2 workspaces
└── ...

Related MCP server: shemcp

Why a Separate Development MCP Server?

ROS 2 runtime interaction and ROS 2 software development have different responsibilities and different safety requirements.

A runtime MCP server needs access to the running ROS graph.

Typical runtime operations include:

list_nodes
list_topics
read_topic
list_services
list_parameters
get_parameter

A development MCP server needs controlled access to project files and development commands.

Typical development operations include:

create_workspace
create_package
create_node
create_launch_file
create_parameter_file
create_tests
build_project
run_tests

Combining both responsibilities in one server would create a larger security boundary and a more complex architecture.

Therefore the projects are intentionally separated.

                   MCP Client
                       |
             +---------+---------+
             |                   |
             v                   v
       ros2_dev_mcp          ros2_mcp
             |                   |
       Development             Runtime
             |                   |
       Workspace               Nodes
       Packages                Topics
       Nodes                   Services
       Launch files            Parameters
       Parameter files         Runtime state
       Tests
       Build
       Test

This also makes future specialized MCP servers easier to add.

Examples:

ros2_control_mcp
moveit2_mcp
nav2_mcp

Phase 1 Responsibilities

Phase 1 focuses on ROS 2 project generation.

The project creation tools are:

create_workspace
create_package
create_node
create_launch_file
create_parameter_file
create_tests

Controlled build and test execution are implemented by the same development server but documented separately in:

docs/README_PHASE_2_BUILD_TEST.md

using:

build_project
run_tests

Architecture

The project creation path is:

MCP Client
    |
    v
ros2_dev_mcp
    |
    v
MCP Project Tools
    |
    v
ProjectService
    |
    v
ProjectAdapter
    |
    v
FilesystemProjectAdapter
    |
    v
SafeFilesystem
    |
    v
Configured Managed Root
    |
    v
ROS 2 Workspace

The layers have separate responsibilities.

MCP Layer

Location:

src/ros2_dev_mcp/mcp/project_tools.py

Responsibilities:

expose project operations as MCP tools
validate MCP tool arguments
obtain the application service from the MCP context
delegate operations to ProjectService
return structured results to the MCP client

The MCP layer does not directly manipulate project files.

Application Layer

Location:

src/ros2_dev_mcp/application/project/service.py

The ProjectService contains the development use cases.

Responsibilities include delegating:

create_workspace
create_package
create_node
create_launch_file
create_parameter_file
create_tests
build_project
run_tests

to the appropriate adapters.

This keeps MCP-specific behavior separate from project implementation details.

Project Adapter

Location:

src/ros2_dev_mcp/project/adapter.py

The Project Adapter defines the interface required by the application layer.

The application service therefore does not need to know how project files are physically created.

The concrete filesystem implementation is located at:

src/ros2_dev_mcp/project/filesystem/adapter.py

This design allows the implementation to evolve without tightly coupling the application layer to filesystem details.

Filesystem Security Boundary

One of the most important requirements of ros2_dev_mcp is that Codex or another MCP client must not receive unrestricted filesystem access through the server.

All project operations are restricted to a configured root directory.

Current managed root:

/home/sarvg/projects/robotics/mcp_workspaces

Equivalent user path:

~/projects/robotics/mcp_workspaces

Configuration file:

config/ros2_dev_mcp.toml

Current configuration:

[project]
allowed_root = "/home/sarvg/projects/robotics/mcp_workspaces"

[execution]
build_timeout_sec = 120.0
test_timeout_sec = 120.0

The managed root is intentionally outside the MCP server repositories themselves.

This means generated projects can be placed here:

~/projects/robotics/mcp_workspaces/test_ws
~/projects/robotics/mcp_workspaces/pubsub_ws
~/projects/robotics/mcp_workspaces/my_robot_ws

while existing projects outside that directory remain outside the project filesystem boundary.

Examples include:

~/projects/robotics/ros2_mcp
~/projects/robotics/ros2_dev_mcp
~/projects/robotics/openmanipulator
~/projects/robotics/turtlebot3
~/projects/robotics/universal_robots
~/projects/robotics/robotics_portfolio_1

The development MCP should not use these existing projects as writable project targets.

SafeFilesystem

The filesystem boundary is implemented by:

src/ros2_dev_mcp/project/filesystem/safe_filesystem.py

SafeFilesystem resolves requested project paths against the configured allowed root.

Its responsibilities include:

resolving relative paths below the allowed root
accepting absolute paths only when they remain below the allowed root
rejecting parent-directory traversal outside the root
resolving paths before validating them
preventing symlink-based escapes from the allowed root

Conceptually:

Requested Path
      |
      v
Resolve Path
      |
      v
Is Path Inside allowed_root?
      |
   +--+--+
   |     |
  Yes    No
   |     |
   v     v
Allow  Reject

Examples of valid targets:

test_ws
pubsub_ws
/home/sarvg/projects/robotics/mcp_workspaces/test_ws

Examples that must be rejected:

../ros2_mcp
../openmanipulator
/tmp/test_ws
/home/sarvg/projects/robotics/ros2_mcp
/home/sarvg/projects/robotics/openmanipulator

This boundary was explicitly verified during development.

Workspace Creation

The MCP tool:

create_workspace

creates a ROS 2 workspace below the configured managed root.

Example MCP request conceptually:

create_workspace(
    workspace_path="test_ws"
)

Result:

~/projects/robotics/mcp_workspaces/test_ws/
└── src/

The workspace follows the standard ROS 2 workspace layout:

workspace/
└── src/

Build directories are not created during workspace creation.

They are generated later by colcon build.

Typical build result:

workspace/
├── build/
├── install/
├── log/
└── src/

Package Creation

The MCP tool:

create_package

creates a ROS 2 Python package inside an existing managed workspace.

Example:

Workspace:
pubsub_ws

Package:
demo_pubsub

Resulting structure:

pubsub_ws/
└── src/
    └── demo_pubsub/
        ├── demo_pubsub/
        │   └── __init__.py
        ├── package.xml
        ├── resource/
        │   └── demo_pubsub
        ├── setup.cfg
        └── setup.py

The generated package uses the ROS 2 Python package structure based on:

ament_python

The package metadata and Python package directory are created automatically.

Node Creation

The MCP tool:

create_node

creates a Python ROS 2 node inside an existing package.

Example:

package:
demo_pubsub

node:
publisher_node

Generated file:

pubsub_ws/
└── src/
    └── demo_pubsub/
        └── demo_pubsub/
            └── publisher_node.py

Another node can be added independently:

subscriber_node.py

Result:

demo_pubsub/
└── demo_pubsub/
    ├── __init__.py
    ├── publisher_node.py
    └── subscriber_node.py

ROS 2 Executable Registration

Creating a Python file alone is not enough for:

ros2 run

Therefore generated nodes are registered as Python console scripts.

Conceptually:

entry_points={
    "console_scripts": [
        "publisher_node = demo_pubsub.publisher_node:main",
        "subscriber_node = demo_pubsub.subscriber_node:main",
    ],
}

After building and sourcing the workspace, ROS 2 can discover the executables.

Example verification:

cd ~/projects/robotics/mcp_workspaces/pubsub_ws
source /opt/ros/jazzy/setup.bash
source install/setup.bash

ros2 pkg executables demo_pubsub

A successfully generated package can expose:

demo_pubsub publisher_node
demo_pubsub subscriber_node

The nodes can then be started with:

ros2 run demo_pubsub publisher_node

and:

ros2 run demo_pubsub subscriber_node

setup.cfg

Generated Python ROS 2 packages include:

setup.cfg

with ROS 2 executable installation paths.

Conceptually:

[develop]
script_dir=$base/lib/demo_pubsub

[install]
install_scripts=$base/lib/demo_pubsub

This is required so installed Python executables are placed where ROS 2 expects them.

Launch File Creation

The MCP tool:

create_launch_file

creates a Python ROS 2 launch file.

Typical result:

demo_pubsub/
└── launch/
    └── demo.launch.py

The launch file can reference one or more nodes from the package.

This allows a higher-level development request such as:

Create a publisher and subscriber and create a launch file
that starts both nodes.

The long-term goal is that Codex can express the intent while ros2_dev_mcp performs the controlled project operations.

Parameter File Creation

The MCP tool:

create_parameter_file

creates a ROS 2 YAML parameter file.

Typical structure:

demo_pubsub/
└── config/
    └── demo_params.yaml

A minimal ROS 2 parameter structure can look like:

publisher_node:
  ros__parameters: {}

Parameter values can later be expanded according to the project requirements.

Configuration files belong to the generated ROS 2 package and remain inside the managed workspace boundary.

Test Creation

The MCP tool:

create_tests

creates basic tests for a generated Python ROS 2 package.

Typical structure:

demo_pubsub/
└── test/
    └── test_package_import.py

The initial test verifies that the generated Python package can be imported correctly.

Additional ROS 2-specific tests can be added in later development phases.

Complete Generated Project Structure

A generated project can therefore look like:

pubsub_ws/
└── src/
    └── demo_pubsub/
        ├── config/
        │   └── demo_params.yaml
        ├── demo_pubsub/
        │   ├── __init__.py
        │   ├── publisher_node.py
        │   └── subscriber_node.py
        ├── launch/
        │   └── demo.launch.py
        ├── package.xml
        ├── resource/
        │   └── demo_pubsub
        ├── setup.cfg
        ├── setup.py
        └── test/
            └── test_package_import.py

After building, the workspace can contain:

pubsub_ws/
├── build/
├── install/
├── log/
└── src/
    └── demo_pubsub/
        └── ...

Configuration

Application configuration is loaded from:

config/ros2_dev_mcp.toml

Configuration loading is implemented in:

src/ros2_dev_mcp/config/settings.py

Current configurable values include:

project.allowed_root
execution.build_timeout_sec
execution.test_timeout_sec

These values are intentionally stored outside the application logic.

This avoids hard-coding environment-specific configuration throughout the source code.

Current Source Structure

The development server is organized as:

src/ros2_dev_mcp/
├── application/
│   ├── __init__.py
│   └── project/
│       ├── __init__.py
│       └── service.py
├── config/
│   ├── __init__.py
│   └── settings.py
├── __init__.py
├── mcp/
│   ├── __init__.py
│   └── project_tools.py
├── project/
│   ├── adapter.py
│   ├── execution/
│   │   ├── adapter.py
│   │   ├── __init__.py
│   │   ├── policy.py
│   │   └── subprocess_adapter.py
│   ├── filesystem/
│   │   ├── adapter.py
│   │   ├── __init__.py
│   │   └── safe_filesystem.py
│   └── __init__.py
└── server.py

The execution layer belongs primarily to the controlled build and test functionality documented in Phase 2.

Development Environment

The current development environment is based on:

Ubuntu 24.04
ROS 2 Jazzy
Python 3.12
uv
MCP Python SDK
colcon

Installation

Create or synchronize the Python environment:

cd ~/projects/robotics/ros2_dev_mcp

uv sync
source .venv/bin/activate

Verify Python:

python --version

The project currently targets:

Python >=3.12,<3.13

Start ros2_dev_mcp Directly

The server can be started directly for development or debugging.

cd ~/projects/robotics/ros2_dev_mcp
source .venv/bin/activate

python -m ros2_dev_mcp.server

The server uses MCP standard I/O transport.

When Codex starts the configured MCP server, starting it manually is normally unnecessary.

Codex Integration

ros2_dev_mcp can be registered as an MCP server in Codex.

cd ~/projects/robotics/ros2_dev_mcp
source .venv/bin/activate

codex mcp add ros2_dev_mcp \
  -- \
  bash -lc 'cd /home/sarvg/projects/robotics/ros2_dev_mcp && source .venv/bin/activate && exec python -m ros2_dev_mcp.server'

Check the registration:

codex mcp get ros2_dev_mcp

List all configured MCP servers:

codex mcp list

Start Codex:

cd ~/projects/robotics/ros2_dev_mcp
source .venv/bin/activate

codex

Inside Codex, inspect available MCP tools with:

/mcp

The expected ros2_dev_mcp tools are:

build_project
create_launch_file
create_node
create_package
create_parameter_file
create_tests
create_workspace
run_tests

Real Codex Verification

The separated development MCP server was tested with Codex.

The request was:

Use only the ros2_dev_mcp MCP server.

Create a new ROS 2 workspace named split_test_ws.

Do not use shell commands.
Do not use direct filesystem operations.
Do not use ros2_mcp.
Do not modify any existing project.

Codex invoked:

ros2_dev_mcp.create_workspace

The resulting workspace was:

/home/sarvg/projects/robotics/mcp_workspaces/split_test_ws
└── src/

This verifies the complete path:

User
  |
  v
Codex
  |
  v
ros2_dev_mcp
  |
  v
Project MCP Tool
  |
  v
ProjectService
  |
  v
FilesystemProjectAdapter
  |
  v
SafeFilesystem
  |
  v
mcp_workspaces

No existing ROS 2 project needed to be modified.

Publisher / Subscriber Development Example

A more complete development workflow was also tested using a publisher/subscriber workspace.

The development target was:

pubsub_ws

with package:

demo_pubsub

and nodes:

publisher_node
subscriber_node

The intended project structure is:

mcp_workspaces/
└── pubsub_ws/
    └── src/
        └── demo_pubsub/
            ├── demo_pubsub/
            │   ├── __init__.py
            │   ├── publisher_node.py
            │   └── subscriber_node.py
            ├── package.xml
            ├── resource/
            │   └── demo_pubsub
            ├── setup.cfg
            └── setup.py

The workspace was successfully built using the development MCP.

After sourcing the built workspace, ROS 2 reported the generated executables:

demo_pubsub publisher_node
demo_pubsub subscriber_node

The nodes were started and discovered by ROS 2.

Example node list:

/publisher_node
/ros2_mcp_runtime
/subscriber_node

This demonstrated that generated project artifacts could progress from MCP project creation to an actual ROS 2 workspace build and runtime discovery.

Example Codex Project Creation Request

A project creation request can be expressed at a high level.

Example:

Use only the ros2_dev_mcp MCP server.

Create a new ROS 2 workspace named pubsub_ws.

Inside it, create a Python package named demo_pubsub.

Create two nodes:

- publisher_node
- subscriber_node

Create a launch file for both nodes.

Create basic tests.

Do not use shell commands.
Do not use direct filesystem operations.
Do not use ros2_mcp.
Do not modify any existing project.

The intended MCP workflow is:

Codex
  |
  v
create_workspace
  |
  v
create_package
  |
  +------------------+
  |                  |
  v                  v
create_node       create_node
publisher         subscriber
  |                  |
  +--------+---------+
           |
           v
 create_launch_file
           |
           v
     create_tests

Build and test operations then continue through Phase 2.

Desired Higher-Level Workflow

The long-term goal is not to require the user to know every individual MCP tool.

Instead, a user should eventually be able to request:

Create a ROS 2 publisher/subscriber example with a launch file,
build it, test it, and report the result.

Codex can then plan the workflow and invoke the required MCP tools:

User Intent
    |
    v
Codex
    |
    +--> create_workspace
    |
    +--> create_package
    |
    +--> create_node
    |
    +--> create_node
    |
    +--> create_launch_file
    |
    +--> create_tests
    |
    +--> build_project
    |
    +--> run_tests
    |
    v
Result

The MCP server provides controlled capabilities.

The MCP client performs the higher-level orchestration.

Important Security Principle

ros2_dev_mcp is not intended to expose a generic shell.

For example, an MCP client should not receive a tool such as:

execute_arbitrary_shell_command

Instead, specific development operations are exposed:

create_workspace
create_package
create_node
create_launch_file
create_parameter_file
create_tests
build_project
run_tests

This creates a much smaller and more understandable security boundary.

Existing Project Protection

The managed workspace boundary is particularly important because the robotics directory contains existing projects.

For example:

~/projects/robotics/
├── mcp_workspaces/
├── oakd/
├── openmanipulator/
├── robotics_portfolio_1/
├── ros2_dev_mcp/
├── ros2_mcp/
├── turtlebot3/
├── universal_robots/
└── zed2/

ros2_dev_mcp project operations are restricted to:

mcp_workspaces/

The MCP development tools therefore have a dedicated area for generated projects instead of operating across the entire robotics directory.

MCP Client Independence

The server uses the Model Context Protocol rather than Codex-specific APIs.

The architecture is therefore:

MCP-compatible Client
        |
        v
ros2_dev_mcp

Codex is currently used as the primary development client.

The design should not intentionally depend on Codex-specific behavior inside the MCP server implementation.

Other MCP-compatible clients can potentially use the same server if they support the required MCP transport and tools.

Independent Implementation

ros2_dev_mcp is developed as an independent implementation.

Other ROS 2 MCP projects can be studied for:

feature comparison
architectural ideas
identifying useful ROS 2 operations
understanding MCP use cases
comparing safety approaches

Their source code is not used as a copy-and-paste implementation basis.

The project should evolve according to its own architecture and requirements.

Relationship to ros2_mcp

The generic ROS MCP architecture is intentionally divided into two primary servers.

ros2_mcp

Responsibility:

ROS 2 Runtime

Examples:

list_nodes
list_topics
topic_info
read_topic
list_services
service_info
node_info
list_parameters
get_parameter

Future runtime capabilities may include controlled:

publish_topic
call_service
set_parameter
ROS 2 actions
process monitoring
launch management
logs
diagnostics

ros2_dev_mcp

Responsibility:

ROS 2 Development

Current capabilities:

create_workspace
create_package
create_node
create_launch_file
create_parameter_file
create_tests
build_project
run_tests

This separation keeps runtime control and source/project manipulation independent.

Future Specialized MCP Servers

The long-term architecture can grow through specialized MCP servers.

MCP Clients
     |
     +-------------------- ros2_mcp
     |                       Generic ROS 2 runtime
     |
     +-------------------- ros2_dev_mcp
     |                       ROS 2 development
     |
     +-------------------- ros2_control_mcp
     |                       ros2_control
     |
     +-------------------- moveit2_mcp
     |                       MoveIt 2
     |
     +-------------------- nav2_mcp
                             Nav2

This prevents the generic ROS MCP server from becoming a monolithic implementation containing every ROS 2 subsystem.

Completed Phase 1 Capabilities

The current development foundation provides:

Separate ros2_dev_mcp server        ✅
Runtime / development separation    ✅
Configurable managed root           ✅
Safe filesystem boundary            ✅
Parent traversal protection         ✅
Symlink escape protection           ✅
Workspace creation                  ✅
Python package creation             ✅
Python node creation                ✅
ROS executable registration         ✅
Launch file creation                ✅
Parameter file creation             ✅
Basic test creation                 ✅
Codex MCP integration               ✅
Real Codex workspace creation       ✅
Existing project isolation          ✅

Phase 1 Design Rules

Phase 1 establishes the following rules:

ROS 2 development and runtime operations remain separated.
Project writes are restricted to a configured managed root.
Existing ROS 2 projects outside that root are not development targets.
Project paths are validated before filesystem operations.
Symlink and parent-path escapes must be rejected.
MCP tools expose specific development capabilities instead of unrestricted filesystem access.
The MCP layer does not directly implement filesystem behavior.
Application logic is separated from concrete adapters.
Configuration values are loaded from configuration files.
MCP clients should remain replaceable.
The implementation remains independent from other ROS MCP projects.
Generated ROS 2 projects should follow normal ROS 2 conventions.
Development features should remain understandable and testable individually.
Specialized ROS 2 subsystems should later receive separate MCP servers where appropriate.

Next Phase

Phase 2 focuses on controlled project execution.

The primary tools are:

build_project
run_tests

The execution path is:

MCP Client
    |
    v
Project MCP Tools
    |
    v
ProjectService
    |
    v
ExecutionAdapter
    |
    v
SubprocessExecutionAdapter
    |
    +--> CommandPolicy
    |
    +--> SafeFilesystem
    |
    v
Controlled Process
    |
    +--> colcon build
    |
    +--> colcon test

Phase 2 adds:

explicit command policy
controlled colcon build
controlled colcon test
package selection
working-directory validation
build timeout
test timeout
structured execution results

See:

docs/README_PHASE_2_BUILD_TEST.md

for the build and test execution architecture.

Available Tools

8 tools

build_projectA

Idempotent

Build a ROS 2 workspace or selected packages using colcon.

ParametersJSON Schema

Name	Required	Description	Default
`package_names`	No
`workspace_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey idempotency and non-destructiveness. The description adds the 'colcon' implementation detail but does not disclose side effects like generated build artifacts, potential long execution time, or environmental requirements. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One succinct sentence that is front-loaded with the action and resource. No wasted words or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema and annotations present, the description is adequate but lacking details about the optional package_names behavior, colcon invocation semantics, and failure modes. It covers the core action but leaves significant operational context to the agent's assumptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so the description must clarify parameters. It hints that 'workspace_path' corresponds to the ROS workspace and 'package_names' to selected packages, but it does not explain path requirements or the behavior of null vs empty list. Partial compensation but incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Build' with resource 'ROS 2 workspace or selected packages' and method 'colcon', making the tool's purpose immediately clear and distinct from sibling tools like create_package or run_tests.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for compiling/building (via colcon) but provides no explicit guidance on when to use it over alternatives. The sibling tool names (create_*, run_tests) offer indirect context, but no clear exclusions or prerequisites are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_launch_fileA

Idempotent

Create a Python ROS 2 launch file inside an existing package.

ParametersJSON Schema

Name	Required	Description	Default
`node_name`	Yes
`launch_name`	Yes
`package_name`	Yes
`workspace_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate the tool is mutating (readOnlyHint=false), non-destructive (destructiveHint=false), and idempotent (idempotentHint=true). The description adds context that the package must already exist, but does not disclose overwrite behavior or other side effects. This adds value beyond annotations but does not fully elaborate on behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. It communicates the essential purpose and scope efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While an output schema exists and annotations cover the safety profile, the description is incomplete for a tool with four required parameters and zero schema descriptions. Critically, it does not mention that the launch file will use node_name to launch a node, nor does it explain how launch_name relates to the file name. This leaves significant gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the absence of parameter explanations. It fails to define workspace_path, package_name, node_name, or launch_name. The parameter names are somewhat self-explanatory, but the description provides no additional guidance, making it difficult for an agent to use the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'create' and clearly identifies the resource as a 'Python ROS 2 launch file' with the scope 'inside an existing package'. It distinguishes itself from sibling tools like create_node or create_package.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'inside an existing package' establishes a clear prerequisite and implies this tool should be used after package creation. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_nodeA

Idempotent

Create a Python ROS 2 node inside an existing package.

ParametersJSON Schema

Name	Required	Description	Default
`node_name`	Yes
`package_name`	Yes
`workspace_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds the prerequisite about existing packages but does not disclose what files are created or modified, whether it validates the package, or the output format. It provides only minimal context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that is front-loaded with the action and resource. Every word adds value, and there is no redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has annotations (idempotent, non-destructive) and an output schema, which reduces the need for the description to explain return values or safety. However, the description does not mention what files are created, package validation, or whether setup files are updated, leaving some uncertainty for a create operation in a ROS 2 context. The description is minimally complete for a simple create tool but lacks operational details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for its three required parameters, and the description provides no additional information about workspace_path, package_name, or node_name. The parameter names are self-explanatory, but the description does not compensate for the missing schema details, leaving the agent to infer meaning from names and context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create') and the resource ('a Python ROS 2 node inside an existing package'), which distinguishes it from sibling tools like create_package or create_workspace. It is specific and unambiguous about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'inside an existing package' implies a prerequisite and suggests usage when adding a node to an already-created package, but it does not explicitly contrast with alternatives or provide when-not-to-use guidance. The context is sufficient but not fully explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_packageC

Idempotent

Create a ROS 2 Python package inside a workspace.

ParametersJSON Schema

Name	Required	Description	Default
`package_name`	Yes
`workspace_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description provides no behavioral details beyond what annotations already specify (idempotentHint=true, destructiveHint=false). It does not explain what happens if the package already exists, what files are created, or whether it modifies the workspace structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, focused sentence with no filler. It is appropriately sized and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is too minimal for a creation tool with two required parameters and potential side effects. It lacks usage context and parameter guidance, leaving the agent to infer important details from the schema and annotations alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no additional context about the required parameters. While parameter names (workspace_path, package_name) are somewhat self-explanatory, the description fails to clarify path requirements, naming conventions, or how the parameters relate to the creation process.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Create a ROS 2 Python package') and its location ('inside a workspace'), distinguishing it from sibling tools like create_workspace or create_node. It provides a precise verb+resource+scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives, no prerequisites or post-conditions, and no exclusions. The usage context is implied only from the name and brief description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_parameter_fileA

Idempotent

Create a ROS 2 parameter YAML file inside an existing package.

ParametersJSON Schema

Name	Required	Description	Default
`node_name`	Yes
`package_name`	Yes
`workspace_path`	Yes
`parameter_file_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false, covering the safety profile. The description adds the precondition that the package must already exist, which is useful context but does not disclose behaviors like overwriting existing files or whether directories are created.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the action and resource. It contains no filler and every word contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is relatively simple and has an output schema, but the description does not explain the relationship between node_name, parameter_file_name, and the generated file's content. The low parameter coverage and lack of usage guidance leave gaps, though the existing-package precondition provides some context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter clarification. It does not explain any of the four parameters (workspace_path, package_name, node_name, parameter_file_name) on its own, though the phrase 'inside an existing package' hints at package_name's role. This is minimal compensation for 0% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create') and the specific resource ('a ROS 2 parameter YAML file'), and distinguishes it from sibling tools by specifying 'inside an existing package.' This is a specific verb+resource+scope, fully differentiating it from other create_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context by stating the tool operates 'inside an existing package,' implying a prerequisite. However, it does not explicitly mention when to use this tool over alternatives like create_launch_file or create_node, nor does it note any exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_testsA

Idempotent

Create basic pytest tests for an existing ROS 2 package.

ParametersJSON Schema

Name	Required	Description	Default
`package_name`	Yes
`workspace_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey idempotent and non-destructive behavior, so the safety profile is known. The description does not add behavioral details beyond what the annotations provide, nor does it contradict them. The word 'basic' hints at limited scope, but no side effects are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is direct and front-loaded with the action and object. Every word is useful, and it is highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations and an output schema present, the description is minimally sufficient for basic selection. However, it lacks details about what 'basic pytest tests' entails (e.g., file locations, dependencies) and any side effects. This is adequate but has clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not clarify the parameters. While names like workspace_path and package_name are plausible, their exact meaning (e.g., workspace root vs package directory) is ambiguous. This is a critical gap for correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'Create basic pytest tests' clearly identifies the action and object. The qualifier 'for an existing ROS 2 package' distinguishes it from sibling tools like create_package or create_node, making the purpose unique.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies a clear use case: adding tests to an existing package. It provides context but does not explicitly name alternatives or exclusion cases (e.g., 'use run_tests to execute tests'). This meets the 'clear context, no exclusions' level.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_workspaceA

Idempotent

Create a ROS 2 workspace inside the configured project root.

ParametersJSON Schema

Name	Required	Description	Default
`workspace_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate the operation is a write (readOnlyHint=false), idempotent (idempotentHint=true), and non-destructive. The description adds location context ('inside the configured project root') but does not disclose potential side effects or behavior when workspace exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant information, earning a perfect score for conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter and has an output schema, but the description lacks parameter guidance and usage context, making it only minimally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must explain the workspace_path parameter. It only hints that the workspace is created inside the project root, leaving the exact path format and meaning unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a ROS 2 workspace within the configured project root, distinguishing it from sibling tools like create_package and create_node which create different resource types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternative guidance is provided. The description implies usage context (creating a workspace as a prerequisite) but does not mention exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_testsB

Idempotent

Run ROS 2 tests for a workspace or selected packages.

ParametersJSON Schema

Name	Required	Description	Default
`package_names`	No
`workspace_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly=false, destructive=false, and idempotent=true, but the description adds no additional behavioral context. It does not mention that running tests may execute arbitrary test code, require a built workspace, or produce side effects from the tests themselves.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that directly states the tool's action and scope. No redundant words or repetition of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple parameter set and an output schema, so the description does not need to explain return values. However, it lacks context about preconditions (e.g., workspace must be built) and the potential impact of executing tests, which would make the description more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds some meaning by mentioning 'workspace or selected packages', which maps to the workspace_path and package_names parameters. However, schema description coverage is 0%, and the description does not explain that omitting package_names runs all tests or clarify the expected format of package_names beyond what the schema shows.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Run') and resource ('ROS 2 tests'), and clearly distinguishes itself from siblings like build_project or create_tests. It also mentions the scoping options (workspace or selected packages), which aligns with the available parameters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives such as build_project or create_tests. The phrase 'for a workspace or selected packages' hints at scope but does not explain prerequisites, when to run tests, or when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct artifact or action in the ROS 2 development lifecycle: workspace, package, node, launch file, parameter file, tests, building, and running tests. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: create_* for scaffolding actions and build_project/run_tests for build/test actions. No mixed conventions or vague verbs.

Tool Count5/5

8 tools is well-scoped for a ROS 2 development server, covering the essential create, build, and test operations without unnecessary redundancy. The count feels proportionate to the server's purpose.

Completeness4/5

The server covers the core Python ROS 2 scaffolding workflow: workspace, package, node, launch, parameters, tests, build, and test. Missing operations like C++ package support or custom interface generation, but the stated Python-focused scope makes these minor gaps.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Superserve
io.github.superserve-ai
MCP server for Superserve sandboxes: create, exec, and manage Firecracker microVMs
Virtualization Code Execution
2417
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
AgentMarketplace A
io.github.raditotev
MCP Server for an Agent Task Marketplace
Autonomous Agents Agent Orchestration
221
Arcjet
com.arcjet
An MCP server for Arcjet - the runtime security platform that ships with your AI code.
Security AI & Machine Learning Code Execution
21

Related MCP Servers

Code Sandbox MCP
Code Execution Virtualization
Automata-Labs-team
A
license
Not graded
quality
B
maintenance
An MCP server to create secure code sandbox environment for executing code within Docker containers.
Updated a year ago (2025-03-23 12:15 UTC)
327
MIT
shemcp
Shell Access Command Line
acartine
A
license
A
quality
C
maintenance
An MCP server that provides sandboxed shell command execution with configurable security policies, enabling safe AI-assisted command runs within a project repository.
Updated 4 months ago (2026-04-25 14:38 UTC)
3
15
2
MIT
Void MCP Filesystem Server
File Systems Developer Tools
EdibleTuber
F
license
Not graded
quality
D
maintenance
A secure, sandboxed MCP server that provides Void Editor with safe filesystem access, enabling AI to create, read, modify, and delete files with comprehensive security controls.
Updated 9 months ago (2025-11-30 17:51 UTC)
1
FieldCure MCP Filesystemofficial
File Systems Developer Tools
fieldcure
A
license
Not graded
quality
C
maintenance
A secure MCP server that exposes local filesystem operations to AI clients with sandboxed access and runtime directory changes.
Updated 3 months ago (2026-05-25 09:09 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vagotec/ros2_dev_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Phase 1 - Safe ROS 2 Project Creation

Goal

Why a Separate Development MCP Server?

Phase 1 Responsibilities

Architecture

MCP Layer

Application Layer

Project Adapter

Filesystem Security Boundary

SafeFilesystem

Workspace Creation

Package Creation

Node Creation

ROS 2 Executable Registration

setup.cfg

Launch File Creation

Parameter File Creation

Test Creation

Complete Generated Project Structure

Configuration

Current Source Structure

Development Environment

Installation

Start ros2_dev_mcp Directly

Codex Integration

Real Codex Verification

Publisher / Subscriber Development Example

Example Codex Project Creation Request

Desired Higher-Level Workflow

Important Security Principle

Existing Project Protection

MCP Client Independence

Independent Implementation

Relationship to ros2_mcp

ros2_mcp

ros2_dev_mcp

Future Specialized MCP Servers

Completed Phase 1 Capabilities

Phase 1 Design Rules

Next Phase

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

FieldCure MCP Filesystemofficial

Latest Blog Posts

MCP directory API