# ros-mcp-server: driving ROS robots from Claude, GPT and Gemini over MCP

> ros-mcp-server bridges MCP clients and ROS 1 or ROS 2 robots through rosbridge, so an LLM can list topics, call services and read sensor data without touching robot source code. The install path is a pip package plus a rosbridge node, and the real constraint is that everything the model does travels over that websocket.

**robotmcp/ros-mcp-server** — Connect AI models like Claude & GPT with robots using MCP and ROS.

- Repository: https://github.com/robotmcp/ros-mcp-server
- Website: https://robotmcp.ai
- Stars: 1,481 · Forks: 214
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/robotmcp-ros-mcp-server

## The gap ros-mcp-server fills between an LLM and a running robot

A language model has no idea what topics exist on your robot. Ask it to move a base and it will invent a topic name, a message type and a field layout, and the command will fail or, worse, half-succeed. The usual fix is to write a bespoke integration for every robot: a wrapper that hardcodes the topics you care about and exposes them to the model. That wrapper breaks the moment someone renames a topic or adds a custom message type.

ros-mcp-server takes the other route. It connects an MCP client to a running ROS graph and lets the model discover what is there. The README describes the design goal as bidirectional communication with no changes to existing robot source code: you add the rosbridge node to your existing ROS setup and the MCP server talks to that. The intended user is an engineer who already has a working robot and wants an assistant to observe and command it, not someone building a robot around an LLM. The repository's examples directory points at the same audience: turtlesim, a LIMO mobile robot, a Unitree Go2, TurtleBot3, plus client-specific folders for Gemini, ChatGPT and Cursor.

## How the server reaches ROS: rosbridge, websockets and tool discovery

The architecture is a chain rather than a single process. The MCP client (Claude Code, Codex CLI, Gemini CLI, Claude Desktop, ChatGPT, Cursor, or anything else speaking the Model Context Protocol) starts or connects to the ros-mcp server. The ros-mcp server, in turn, opens a websocket to a rosbridge node running inside your ROS graph. Every publish, subscribe, service call, action call or parameter read crosses that websocket.

That is why the dependency list in pyproject.toml includes websocket-client alongside fastmcp and mcp[cli]. It is also why the project claims ROS 1 and ROS 2 support with the same server: rosbridge exists for both, and the server speaks to the bridge rather than to a specific ROS client library. The README states compatibility with ROS 2 Jazzy and Humble among others, and with ROS 1 distros.

The interesting part is discovery. The README says the server guides the model to find available topics, services and actions along with their types, including custom ones, so the model can construct the right syntax without manual configuration. The repository ships a robot_specifications package containing YAML files, which suggests per-robot hints are data rather than code, though the README does not document their schema. Treat that directory as something to read before assuming the model will infer everything on its own.

## Installing ros-mcp and running a first turtlesim session

The README does not inline installation steps; it points to docs/install/installation.md. What the packaging makes clear is that the project is distributed as a Python package named ros-mcp, requiring Python 3.10 or newer, and that it exposes a console entry point called ros-mcp. The README badge also lists pip 23.0 or newer. A dev container is provided in .devcontainer/ for people who would rather not install ROS locally.

Assuming you have a ROS environment with rosbridge available and an MCP client installed, the server side is a single command:

```bash
ros-mcp
```

What you should see depends on how the server is launched: the README describes it as an MCP server, so the normal pattern is that your MCP client spawns it over stdio rather than you running it in a terminal. The installation guide is the authority on the exact client configuration for each supported client; the repository keeps separate example folders for ChatGPT and Cursor, which is a sign the wiring differs per client.

On the robot side, the missing piece is rosbridge itself. The README's stated workflow is to add the rosbridge node to your existing ROS setup, and the repository has a launch/ directory for that purpose. Once the bridge is up and the MCP client is connected, the first useful prompt is not a movement command but an inventory request: ask the model to list the available topics and their types. If it returns your real topic list instead of plausible-sounding names, the websocket path and the discovery mechanism are both working. Only then try a service call on something harmless, such as a turtlesim reset, before touching anything that moves.

## Where ros-mcp-server is the wrong tool

The dependency on rosbridge is a hard boundary, not a preference. If your robot runs a minimal ROS image without rosbridge, or a vendor stack you cannot add nodes to, the server has nothing to talk to. The README frames the rosbridge requirement as the reason no source changes are needed, which is a fair trade, but it means the answer to "can I use this on my locked-down controller" is often no.

Safety is the second boundary. The README's feature list covers publishing, subscribing, calling services and actions, setting parameters and reading sensors. It does not describe an approval step, a command allowlist or a dry-run mode. The contributing section lists Action support and permissions as features people are invited to build, which tells you permissions are not a shipped capability. An LLM with publish access to a velocity topic has publish access to a velocity topic. The examples in the README are demonstrations, not safety architectures.

The third boundary is the model's own reliability. Discovery reduces guessing about topic names and message fields, but the README's industrial-robot example is framed as the model finding an anomaly after running its own tests. That is a compelling story about diagnosis; it is not evidence that the model will avoid sending a malformed command to a production cell. Latency is also worth measuring yourself: every tool call is a round trip through the MCP client, the server and the websocket, and the README makes no timing claims.

## ros-mcp-server compared with hand-written ROS integrations

The closest alternative is not another MCP server. It is the script you would write yourself: a small node or service that subscribes to the topics you care about and exposes a fixed set of functions to a model through a function-calling API. That approach has real advantages. You control exactly which capabilities exist, you can validate arguments before publishing, and you can encode domain rules such as refusing a velocity above a limit. The cost is that the interface is frozen at the moment you write it. New sensor, new topic, new message type: back to the code.

ros-mcp-server inverts that. Capability comes from whatever is currently running in the ROS graph, discovered at conversation time, including custom types. You write no integration code and you get the whole graph. You also get the whole graph as an attack surface, and you depend on the model to choose the right topic from a list rather than on a function signature you designed. For a research robot or a simulator, that trade is usually worth it. For a production line where an unintended publish has physical consequences, a narrow hand-written interface with explicit validation is the more defensible design, and ros-mcp-server is better used for read-only observation there.

Within the MCP ecosystem itself, the comparison that matters is client support rather than competing servers: the README lists Claude Code, Codex CLI, Gemini CLI, Claude Desktop, ChatGPT and Cursor, and the repository carries example folders for several of them. That breadth comes from the MCP standard, not from anything ROS-specific.

## Licence, maintenance and what an upgrade actually costs

The project is Apache-2.0, stated in both the README and pyproject.toml. For most teams that is the permissive case: you can use it commercially, modify it and ship it, provided you keep the licence and notices intact. Apache-2.0 also contains an explicit patent grant, which matters more in robotics than in web tooling. This is a description of the licence text, not legal advice; if you are redistributing the server inside a product, have counsel read the NOTICE and attribution requirements rather than relying on a summary.

Maintenance looks current. The repository is not archived, and the last push was on 2026-09-10. Releases are spaced rather than continuous: v3.0.0 and v3.0.1 both landed on 2026-01-29, and v3.1.0 on 2026-06-17. The version in pyproject.toml matches v3.1.0, so the package metadata tracks the release tag.

The upgrade cost is mostly the dependency surface. pyproject.toml pins minimums, not exact versions, for fastmcp, mcp[cli], jsonschema, websocket-client, opencv-python and pillow. The MCP libraries in particular are young and move quickly, so a minor bump in mcp or fastmcp can change tool-call behaviour without any change in ros-mcp itself. The project ships a uv.lock, which is the practical answer: resolve from the lockfile, and when you upgrade, upgrade the lockfile as one unit rather than letting a transitive MCP release drift in underneath you. The Python floor of 3.10 is the other constraint to check against your ROS distribution's default interpreter before you commit.

## Conclusion

Adopt ros-mcp-server if you already run ROS 1 or ROS 2 and want an MCP client to inspect topics, services, actions and parameters without editing robot code, especially for debugging and supervised teleoperation. Do not adopt it if your stack has no rosbridge and you cannot add one, or if you expect the server to decide what the robot is allowed to do: the README describes no permission layer, and the contributing notes list permissions as a wanted feature. Before wiring it into anything that moves, verify three things on your own robot: that the rosbridge websocket accepts connections from the machine running the MCP server, that ros-mcp can enumerate your custom message and service types, and that your MCP client shows you each tool call before it executes.

## FAQ

### What does an MCP server actually do?

It exposes capabilities to a model through the Model Context Protocol, so an MCP client can call them as tools. In ros-mcp-server those tools cover ROS operations such as publishing and subscribing to topics, calling services and actions, setting parameters and reading sensor data. The README describes it as connecting LLMs like Claude, GPT and Gemini to robots over that standard.

### What is ROS used for, and does ros-mcp-server require it?

ROS is the robotics middleware the server targets; the README states compatibility across ROS 2 distributions such as Jazzy and Humble as well as ROS 1 distros. The server does not replace ROS. It talks to a rosbridge node running inside your existing ROS graph, which is why no robot source code changes are needed.

### Does ros-mcp-server still exist and is it maintained?

The repository is not archived and the last push was on 2026-09-10. The most recent release listed is v3.1.0 from 2026-06-17, and pyproject.toml carries version 3.1.0. Releases are spaced months apart rather than continuous.

## Sources

- [License: Apache-2.0](https://github.com/robotmcp/ros-mcp-server/blob/main/LICENSE)
- [Project website](https://robotmcp.ai)
- [README](https://github.com/robotmcp/ros-mcp-server/blob/main/README.md)
- [Releases](https://github.com/robotmcp/ros-mcp-server/releases)
- [robotmcp/ros-mcp-server on GitHub](https://github.com/robotmcp/ros-mcp-server)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/robotmcp-ros-mcp-server