CoppeliaSim MCP Server
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 🤖🚀
High-efficiency, token-optimized Model Context Protocol (MCP) server providing direct integration between AI agents (Claude Desktop, omp, Cursor, Windsurf, Zed) and the CoppeliaSim robotics simulator.
✨ Features
⚡ Token-Optimized (
coppelia_step): Single unified tool call replacing fragmented multi-round trips. Auto-launches, runs code, extracts floor & hierarchy, and captures multimodal snapshots in one request.👁️ Dual-Camera Visual Eyes:
topdown_snapshot(/tmp/coppelia_topdown.png): Bird's-eye view above the simulation board to verify 2D placement, room boundaries, and navigation.snapshot(/tmp/coppelia_snapshot.png): Elevated isometric 3D perspective to verify object heights, wall alignment, and robot upright stability.
📐 Auto Floor & Scene Hierarchy Awareness: Returns exact floor bounding box (
size_x,size_y,surface_z) and existing scene objects (scene_objects) on every turn to prevent duplicate models.🤖 Built-in Robot Catalog: Injected
load_robot(alias, [x, y, z])supporting pre-tested models:Mobile:
'pioneer','youbot','hexapod','ant_hexapod','omni','quadcopter','asti','epuck','vacuum'Manipulators:
'panda','ur5','ur10'
🛡️ Self-Documenting Zero-Discovery: Complete API cheat-sheet and constants embedded in tool schema so agents do not waste tokens guessing functions.
Related MCP server: MuJoCo MCP Server
📋 Prerequisites
CoppeliaSim (v4.3+ recommended, Linux / macOS / Windows) with ZeroMQ Remote API enabled (default port
23000).Python >= 3.10.
🚀 Installation & Setup
Clone the repository and install dependencies in an isolated virtual environment:
git clone https://github.com/nashirabbash/coppeliasim-mcp.git
cd coppeliasim-mcp
# Setup environment
chmod +x setup_env.sh
./setup_env.sh🔌 Configuration Across Agent Harnesses
1. omp Harness
Add to ~/.omp/agent/mcp.json:
{
"mcpServers": {
"coppeliasim": {
"type": "stdio",
"command": "/path/to/coppeliasim-mcp/.venv/bin/python",
"args": [
"/path/to/coppeliasim-mcp/coppelia_mcp.py"
],
"enabled": true
}
}
}2. Claude Desktop
Add to ~/.config/Claude/claude_desktop_config.json (Linux) or ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"coppeliasim": {
"command": "/path/to/coppeliasim-mcp/.venv/bin/python",
"args": [
"/path/to/coppeliasim-mcp/coppelia_mcp.py"
]
}
}
}3. Cursor / Windsurf / Zed
Add to your workspace .cursor/mcp.json or global settings:
{
"mcpServers": {
"coppeliasim": {
"command": "/path/to/coppeliasim-mcp/.venv/bin/python",
"args": [
"/path/to/coppeliasim-mcp/coppelia_mcp.py"
]
}
}
}🛠️ Tool Schema: coppelia_step
The agent interacts via a single function:
coppelia_step(
code: str = "", # Python code manipulating scene (sim.* and load_robot)
reset: bool = False, # If True, stops simulation before execution
headless: bool = False # If True, launches simulator without GUI
)Injected Environment
Inside the code string, the script directly accesses:
sim: CoppeliaSim ZeroMQ API module.load_robot(alias, position=[x, y, z]): Loads pre-built robot model.get_floor_info(): Current floor boundaries and elevation.get_scene_hierarchy(): Currently active scene shapes and models.capture_snapshot(): Captures camera frame.
Response Payload
{
"success": true,
"stdout": "...",
"floor": {
"size_x": 5.0,
"size_y": 5.0,
"bounds_x": [-2.5, 2.5],
"bounds_y": [-2.5, 2.5],
"surface_z": 0.0
},
"scene_objects": [
{"name": "PioneerP3DX", "handle": 25, "is_model": true, "pos": [0.0, 0.0, 0.3]}
],
"snapshot": "/tmp/coppelia_snapshot.png",
"topdown_snapshot": "/tmp/coppelia_topdown.png",
"eye_evaluation_directive": "EVALUATE YOUR EYES: Read /tmp/coppelia_topdown.png and /tmp/coppelia_snapshot.png before replying."
}📊 Benchmark & Evaluation
Run the automated evaluation benchmark:
./run_benchmark.shMeasures token consumption, tool invocation count, physical scene reality, and visual validity.
📜 License
MIT License. See LICENSE for details.
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
OCR, 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.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
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.59 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
- AlicenseAqualityBmaintenanceExposes 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