Skip to main content
Glama
nashirabbash

CoppeliaSim MCP Server

by nashirabbash

CoppeliaSim MCP Server

Build and inspect CoppeliaSim scenes from an AI assistant through one MCP tool.

License: MIT

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.

Architecture: MCP client calls the server, runner uses CoppeliaSim, and snapshots are saved locally

View editable architecture diagram.

What you can do

  • Create shapes, load bundled robot models by alias, and control simulation with CoppeliaSim's sim API.

  • Inspect the current floor and scene hierarchy before adding objects.

  • Check both camera views after each successful execution: /tmp/coppelia_topdown.png and /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_ROOT to 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/coppeliaSim

Try 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

code

""

Python executed with sim, client, simIK, simOMPL, load_robot, get_floor_info, get_scene_hierarchy, and snapshot helpers. Empty code captures the current scene.

reset

false

Stops a running simulation before executing code; does not clear scene objects.

headless

false

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.

Execution flow: code errors, successful snapshot capture, and snapshot warnings return different results

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 port 23000. Automatic launch scripts assume author-specific absolute paths; launch manually on other machines.

  • Failed to import coppeliasim_zmqremoteapi_client: Check COPPELIASIM_ROOT points to the CoppeliaSim directory containing programming/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-robots to inspect alias paths or pass an existing .ttm path to load_robot.

  • No snapshots: Check stderr in the tool response. Snapshots are written to /tmp only 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 tool
coppelia_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:

  1. /tmp/coppelia_topdown.png (TOP-DOWN BIRD'S-EYE VIEW of entire board)

  2. /tmp/coppelia_snapshot.png (ISOMETRIC 3D PERSPECTIVE VIEW of structures)

MANDATORY PROTOCOL AFTER EVERY CALL:

  1. You MUST explicitly read and inspect BOTH image files using your image viewing / file inspection capabilities.

  2. Check /tmp/coppelia_topdown.png to verify: 2D room dimensions, obstacle spacing, robot heading, and boundary clearance.

  3. Check /tmp/coppelia_snapshot.png to verify: wall heights (e.g. 5m), roof alignment, upright robot stability, and no physical sagging or collision clipping.

  4. 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:

  1. DO NOT spawn a robot if a model with the same alias/name already exists in scene_objects.

  2. To reuse existing robot: robot = sim.getObject('/PioneerP3DX') (or use existing handle).

  3. 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!

  1. 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!).

  2. 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!

  3. 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):

  1. 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

  2. Positions & Hierarchy:

    • Set position: sim.setObjectPosition(handle, -1, [x, y, z]) # -1 = absolute world coords

    • Get 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)

  3. Collision & Distance Detection:

    • Collision check: result, collPair = sim.checkCollision(entity1Handle, entity2Handle) # 1 = colliding, 0 = clear

    • Distance check: result, distData = sim.checkDistance(entity1Handle, entity2Handle, threshold)

  4. Path & Motion Planning (simOMPL & simIK):

    • simOMPL Task: task = simOMPL.createTask('task_name')

    • Set Algorithm: simOMPL.setAlgorithm(task, simOMPL.Algorithm.RRTConnect) # or RRTstar, PRM

    • Compute 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)

  5. 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()
ParametersJSON Schema
NameRequiredDescriptionDefault
codeNo
resetNo
headlessNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior4/5

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.

Conciseness2/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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. 1 tool updatev0.1.0
    • First observedcoppelia_step

TDQS

A3.9/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count3/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Exposes MuJoCo physics simulation to AI assistants via 65 MCP tools, enabling natural language control of robotics simulation, trajectory optimization, contact analysis, and video export.
    8
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables LLMs to create and manipulate 3D models using OpenSCAD through MCP tools for code-based modeling, preview, and export.
    1
    MIT
  • A
    license
    A
    quality
    D
    maintenance
    Exposes 12 robotics/simulation tools from robosimtools.com as MCP tools, enabling AI agents to perform conversions (quaternion, URDF, MJCF), validation, and CAD imports locally.
    12
    1
    MIT