CoppeliaSim MCP Server
You can use this MCP server to execute Python inside a live CoppeliaSim scene, build/inspect/refine it, and get visual snapshots through one coppelia_step tool.
Run arbitrary Python code against CoppeliaSim with injected
sim,simIK,simOMPL,client, and helper functions.Create and color primitive shapes like cuboids, cylinders, and spheres; set them static or respondable.
Load bundled robot models by alias (e.g.
pioneer,youbot,panda,ur5) and position/orient them.Inspect floor details, scene hierarchy, and existing
scene_objectsto avoid duplicates.Control simulation: start/stop, set joint velocities, read proximity sensors, and check collisions or distances.
Use motion planning and kinematics tools via
simOMPLandsimIK.Auto-capture top-down and isometric snapshots after successful execution for visual verification.
Return JSON with execution output, success status, floor/scene data, and snapshot paths when available.
Optionally reset a running simulation before execution or request headless mode if CoppeliaSim must be launched.
Click on "Deploy 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., "@CoppeliaSim MCP ServerLoad a Pioneer robot at the origin and show me the snapshots."
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.
CoppeliaSim MCP Server
Build and inspect CoppeliaSim scenes from an AI assistant through one MCP tool.
Connect an MCP client to CoppeliaSim's ZeroMQ Remote API. coppelia_step runs Python against the current scene and returns execution output, floor information, scene objects, and paths to top-down and isometric snapshots. The scene persists between calls, so an agent can inspect and refine it without recreating everything.

View editable architecture diagram.
What you can do
Create shapes, load bundled robot models by alias, and control simulation with CoppeliaSim's
simAPI.Inspect the current floor and scene hierarchy before adding objects.
Check both camera views after each successful execution:
/tmp/coppelia_topdown.pngand/tmp/coppelia_snapshot.png.Use the same runner directly from the command line or through an MCP client.
Related MCP server: MuJoCo MCP Server
Get started
Requirements
Python 3.10 or newer and CoppeliaSim with its ZeroMQ Remote API addon available on port
23000.A local CoppeliaSim installation with the bundled Python client and robot models. Set
COPPELIASIM_ROOTto its installation directory if it is not at/home/myarchlinux/.local/opt/coppeliaSim.An MCP-compatible client for agent use; the command-line runner works without one.
Install
git clone https://github.com/nashirabbash/coppeliasim-mcp.git
cd coppeliasim-mcp
bash setup_env.sh
.venv/bin/python -m pip install -e .setup_env.sh creates .venv and installs runner dependencies; pip install -e . also installs the MCP server dependency. Start CoppeliaSim yourself and confirm its ZeroMQ Remote API addon is listening on port 23000. This is the portable route: automatic launch currently uses installation paths hard-coded for the original author's machine.
For installations elsewhere, set COPPELIASIM_ROOT before running the CLI or starting the MCP client (or set it in the client's server environment):
export COPPELIASIM_ROOT=/path/to/coppeliaSimTry the local runner without changing the scene:
./coppelia_run --code 'print(get_floor_info())'It prints JSON with success, captured output, floor and scene objects, and snapshot paths when image capture succeeds. Open both snapshot files to check actual placement; success: true only confirms Python code ran, not that geometry or physics is correct. If no simulator is connected, the command reports a connection error instead.
Connect an MCP client
Find the absolute path to this checkout, then replace /absolute/path/to/coppeliasim-mcp below. For omp, add this server to ~/.omp/agent/mcp.json (merge it with existing mcpServers entries):
{
"mcpServers": {
"coppeliasim": {
"type": "stdio",
"command": "/absolute/path/to/coppeliasim-mcp/.venv/bin/python",
"args": ["/absolute/path/to/coppeliasim-mcp/coppelia_mcp.py"],
"enabled": true
}
}
}For Claude Desktop, use its claude_desktop_config.json (~/.config/Claude/ on Linux or ~/Library/Application Support/Claude/ on macOS) with the same command and args under mcpServers; omit type and enabled. Other stdio MCP clients can use the same executable and script paths. Restart your client after editing its configuration.
Use the tool
Ask your client to call coppelia_step with Python source in code. Example:
# coppelia_step(code="...")
print(get_floor_info())
print(get_scene_hierarchy())
robot = load_robot('pioneer', [0.0, 0.0, 0.3])
print(sim.getObjectPosition(robot, -1))Check scene_objects first so repeated calls do not load another copy of the robot. load_robot uses .ttm models under COPPELIASIM_ROOT/models; aliases include pioneer, youbot, hexapod, ant_hexapod, omni, quadcopter, epuck, vacuum, panda, ur5, and ur10. Available models depend on your CoppeliaSim installation; run ./coppelia_run --list-robots for the full alias map.
Parameter | Default | Behavior |
|
| Python executed with |
|
| Stops a running simulation before executing code; does not clear scene objects. |
|
| Requests headless mode only if the server needs to launch CoppeliaSim. |
Response is JSON text containing success, stdout, and, when available, stderr, error, floor, scene_objects, snapshot, and topdown_snapshot. Snapshot paths are omitted if capture fails. Inspect both views before treating a scene as finished.

View editable execution-flow diagram.
Command-line runner
./coppelia_run --code 'print(get_scene_hierarchy())'
./coppelia_run --file path/to/scene.py
./coppelia_run --reset --code 'sim.startSimulation()'Runner accepts --host and --port for an existing remote simulator; MCP tool uses its default localhost port 23000. --reset stops simulation, not object removal. For CLI options, run ./coppelia_run --help.
Troubleshooting
Cannot connect to
localhost:23000: Start CoppeliaSim, enable its ZeroMQ Remote API addon, and verify port23000. Automatic launch scripts assume author-specific absolute paths; launch manually on other machines.Failed to import coppeliasim_zmqremoteapi_client: CheckCOPPELIASIM_ROOTpoints to the CoppeliaSim directory containingprogramming/zmqRemoteApi/clients/python/src, then rerun with the project virtual environment.Robot model not found: Check the model exists beneath
COPPELIASIM_ROOT/models. Use./coppelia_run --list-robotsto inspect alias paths or pass an existing.ttmpath toload_robot.No snapshots: Check
stderrin the tool response. Snapshots are written to/tmponly after successful code execution and capture; they are local to the machine running the server.
Contributing
Issues and pull requests are welcome at github.com/nashirabbash/coppeliasim-mcp. For local development, use the install steps above and verify basic CLI behavior with ./coppelia_run --list-robots. A live simulator is required to verify scene changes and camera output. The optional ./run_benchmark.sh exercises agent-driven scenes and requires a configured omp client; it changes the active simulation, so use a disposable scene.
License
MIT.
Available Tools
1 toolcoppelia_stepA
🚨 STRICT SUPREME DIRECTIVE FOR AI AGENT (READ THIS FIRST): NEVER CONCLUDE OR REPORT SUCCESS BASED SOLELY ON CODE LOGS OR EXIT STATUS! You are interacting with a physical 3D simulation environment. Code that executes without error often produces physically broken scenes (e.g. walls collapsing under gravity, objects intersecting, robots falling through floors or flipped upside-down).
THEREFORE, YOU ARE STRICTLY REQUIRED TO USE YOUR EYES: Every call returns TWO visual snapshots:
/tmp/coppelia_topdown.png(TOP-DOWN BIRD'S-EYE VIEW of entire board)/tmp/coppelia_snapshot.png(ISOMETRIC 3D PERSPECTIVE VIEW of structures)
MANDATORY PROTOCOL AFTER EVERY CALL:
You MUST explicitly read and inspect BOTH image files using your image viewing / file inspection capabilities.
Check
/tmp/coppelia_topdown.pngto verify: 2D room dimensions, obstacle spacing, robot heading, and boundary clearance.Check
/tmp/coppelia_snapshot.pngto verify: wall heights (e.g. 5m), roof alignment, upright robot stability, and no physical sagging or collision clipping.IF YOUR EYES SEE ANY VISUAL DEFECT (collapsed wall, misplaced robot, clipping mesh), YOU MUST NOT CLAIM COMPLETION. You must immediately self-correct your script coordinates and run again! Reporting "Task complete" without having visually verified both screenshots is a fatal protocol violation.
TOOL SUMMARY: Execute Python code directly inside CoppeliaSim simulator. Auto-launches simulator if closed, runs physics/scene code, auto-captures dual camera snapshots, and returns execution result in ONE single call.
SCENE HIERARCHY AWARENESS RULE (PREVENT DUPLICATE MODELS):
Every call returns "scene_objects": [{"name": "...", "is_model": bool, "pos": [x, y, z]}].
ALWAYS inspect scene_objects before creating/spawning:
DO NOT spawn a robot if a model with the same alias/name already exists in
scene_objects.To reuse existing robot:
robot = sim.getObject('/PioneerP3DX')(or use existing handle).To remove duplicate/old objects:
sim.removeObject(sim.getObject('/OldName')).
WALLS & ENCLOSURE VISIBILITY RULE (PREVENT GREY VOID BLINDNESS): NEVER build solid block labyrinths or closed rooms that entomb the camera/robot in solid gray geometry!
DO NOT spawn 50+ individual solid wall cuboids for mazes. Use thin perimeter borders instead (thickness 0.1m - 0.2m, NOT 0.8m thick blocks!).
Color your walls and floor distinctly (e.g. walls = light blue
[0.3, 0.6, 0.9], floor = dark grey[0.2, 0.2, 0.2]). NEVER leave all shapes default uncolored grey!If creating rooms or houses with roofs: DO NOT seal roofs with solid opaque material. Either leave roof off, or make it high and distinctly colored so internal contents remain visible.
INJECTED OBJECTS IN CODE:
sim: CoppeliaSim ZeroMQ API module.simIK: CoppeliaSim Inverse/Forward Kinematics solver module.simOMPL: Open Motion Planning Library module (RRT, RRT*, PRM path planners).load_robot(alias, position=[x,y,z], orientation=[a,b,g]): Loads robot model. Valid aliases: ['pioneer', 'youbot', 'hexapod', 'ant_hexapod', 'omni', 'quadcopter', 'asti', 'panda', 'ur5', 'ur10', 'vacuum', 'epuck'].get_scene_hierarchy(): Returns current active user models and shapes in the scene.get_floor_info(): Returns default floor size, position, and bounding box.client: RemoteAPIClient instance.
EXACT API CHEAT-SHEET (DO NOT SEARCH OR GUESS - USE THESE DIRECTLY):
Shapes & Environment:
Create cuboid:
h = sim.createPrimitiveShape(sim.primitiveshape_cuboid, [sizeX, sizeY, sizeZ], 0)Create cylinder:
h = sim.createPrimitiveShape(sim.primitiveshape_cylinder, [diameter, diameter, height], 0)Create sphere:
h = sim.createPrimitiveShape(sim.primitiveshape_sphere, [diameter, diameter, diameter], 0)Make static (walls/floors/roofs):
sim.setObjectInt32Param(h, sim.shapeintparam_static, 1)Make respondable (solid collisions):
sim.setObjectInt32Param(h, sim.shapeintparam_respondable, 1)Color shape:
sim.setShapeColor(h, None, sim.colorcomponent_ambient_diffuse, [R, G, B])# values 0.0 - 1.0
Positions & Hierarchy:
Set position:
sim.setObjectPosition(handle, -1, [x, y, z])# -1 = absolute world coordsGet position:
pos = sim.getObjectPosition(handle, -1)# returns [x, y, z]Set orientation:
sim.setObjectOrientation(handle, -1, [alpha, beta, gamma])Find object by name:
h = sim.getObject('/ObjectName', {'noError': True})Remove object:
sim.removeObject(handle)
Collision & Distance Detection:
Collision check:
result, collPair = sim.checkCollision(entity1Handle, entity2Handle)# 1 = colliding, 0 = clearDistance check:
result, distData = sim.checkDistance(entity1Handle, entity2Handle, threshold)
Path & Motion Planning (simOMPL & simIK):
simOMPL Task:
task = simOMPL.createTask('task_name')Set Algorithm:
simOMPL.setAlgorithm(task, simOMPL.Algorithm.RRTConnect)# or RRTstar, PRMCompute Path:
solved, path = simOMPL.compute(task, maxTime=4.0)simIK Solver:
env = simIK.createEnvironment(); simIK.addElementFromScene(env, ikGroup, tip, target, base)Native Path Interpolation:
pathHandle = sim.createPath(ctrlPoints, options)
Simulation & Motors:
Start simulation:
sim.startSimulation()Stop simulation:
sim.stopSimulation()Set motor velocity:
sim.setJointTargetVelocity(jointHandle, float_val)Read proximity sensor:
detected, dist, pt, obj, normal = sim.readProximitySensor(sensorHandle)
sim.stopSimulation()
# House floor
floor = sim.createPrimitiveShape(sim.primitiveshape_cuboid, [10.0, 10.0, 0.2], 0)
sim.setObjectInt32Param(floor, sim.shapeintparam_static, 1)
sim.setObjectInt32Param(floor, sim.shapeintparam_respondable, 1)
# Spawn robot inside
robot = load_robot('pioneer', [0.0, 0.0, 0.3])
sim.startSimulation()| Name | Required | Description | Default |
|---|---|---|---|
| code | No | ||
| reset | No | ||
| headless | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and largely meets it: it discloses that the tool auto-launches a simulator, runs physics, writes two PNG files to /tmp, and returns scene_objects plus an execution result in one call. These are non-obvious side effects an agent must know. It does not discuss failure modes like timeouts, simulator crash behavior, or whether state persists across calls.
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 definition opens with an all-caps 'STRICT SUPREME DIRECTIVE' block of alarmist, repetitive prose before ever stating what the tool does, which inverts the front-loading principle. Much of the framing ('fatal protocol violation', restated warnings) is redundant, though the API cheat-sheet and example carry genuine value. Size is far beyond what the task requires.
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 executes arbitrary code against a live simulator, the description covers a lot of the practical surface: environment modules, helper functions, API calls, and known pitfalls. An output schema exists, so return values need not be re-explained. The gaps are the unaddressed `reset` and `headless` flags and any note on state persistence between calls.
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 0%, so the description must compensate for all three parameters. It thoroughly explains the `code` parameter (injected modules, load_robot aliases, full API cheat-sheet, an example), but `reset` and `headless` are never mentioned anywhere in the text. Compensating for one of three parameters is partial, warranting a mid 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 TOOL SUMMARY states a specific verb and resource: 'Execute Python code directly inside CoppeliaSim simulator', plus a compact account of auto-launch, physics execution, and dual snapshot capture. The purpose is unambiguous once found, but it is buried under a long directive preamble rather than front-loaded. No siblings exist to differentiate from, which caps this below a 5.
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?
It gives concrete when-to-do guidance: inspect scene_objects before spawning, reuse an existing model instead of duplicating, remove old objects, and always visually verify both screenshots before declaring success. What it lacks is any explicit statement of when NOT to use this tool or what alternatives exist (none are provided as siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
coppelia_step
TDQS
Scored across 1 tool
Only one tool exists, so there is no risk of selecting the wrong tool or overlapping purposes among tools. The tool's purpose (execute Python in CoppeliaSim and return snapshots) is clearly stated.
With a single tool named coppelia_step, there is no inconsistency to evaluate. The name follows a predictable server-prefixed snake_case pattern and clearly indicates the action.
A single tool is on the thin side for a complex 3D simulation and robotics domain, even though the tool is powerful and general-purpose. The rubric treats 1-2 tools as borderline, so this lands at 3.
The tool provides arbitrary Python execution plus injected CoppeliaSim APIs, robot loading, scene hierarchy inspection, and visual snapshots, so essentially any simulation operation can be performed. No obvious capability is missing from the surface.
Maintenance
Related MCP Connectors
214 tools for AI agents over one MCP endpoint: image, video, audio, 3D, data, storage, mail, GPUs.
1OCR, transcription, file extraction, and image generation for AI agents via MCP.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Multiple MCP tools, persistent graph memory, token-saving data pointers, and more.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to control a Minecraft bot for movement, building, crafting, and instant schematic-based structure spawning via MCP tools.46 npm2Apache 2.0
- AlicenseNot gradedqualityDmaintenanceExposes MuJoCo physics simulation to AI assistants via 65 MCP tools, enabling natural language control of robotics simulation, trajectory optimization, contact analysis, and video export.8MIT
- AlicenseNot gradedqualityDmaintenanceEnables LLMs to create and manipulate 3D models using OpenSCAD through MCP tools for code-based modeling, preview, and export.1MIT
- AlicenseAqualityDmaintenanceExposes 12 robotics/simulation tools from robosimtools.com as MCP tools, enabling AI agents to perform conversions (quaternion, URDF, MJCF), validation, and CAD imports locally.121MIT