MCP server to drive CoppeliaSim 4.10 from Claude Code and other MCP clients, without exposing arbitrary Lua execution
CoppeliaSim MCP has well-structured tool definitions with consistent naming (verb_noun pattern: crear_*, fijar_*, listar_*) and complete input schemas across all 20 tools. Descriptions are present and moderately detailed (avg ~120 chars), explaining WHAT each tool does and WHEN to use it. However, descriptions lack actionable recovery guidance for errors, and output schemas are not documented. Parameter descriptions are adequate but could be more prescriptive about constraints and formats. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification in metadata. Security-conscious design (no Lua execution, path traversal protection) is evident in code but not reflected in tool descriptions.
Deletes an object from the scene
Loads a scene file from the configured scenes directory
Loads a model from the CoppeliaSim models library
Checks proximity sensor detection on demand (works with simulation stopped)
Creates a joint (revolute or prismatic) with motor control
Creates a primitive shape (cube, sphere, cylinder, cone, capsule, disc, torus)
Creates a proximity sensor (cone or pyramid type)
No output schemas documented. LLMs cannot infer what fields each tool returns, forcing them to guess downstream parameter mappings and risking broken tool chains.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification in metadata (READ_ONLY, WRITE, DESTRUCTIVE). Agents cannot distinguish safe reads from destructive writes without parsing descriptions.
Error handling guidance missing. Descriptions do not explain what to do if a tool fails (e.g., 'object not found, try listar_objetos first'). Agents will retry blindly or give up.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Creates a rigid connection between two dynamic shapes using a force sensor
Sets the parent of an object in the scene hierarchy
Marks a shape as detectable by proximity sensors
Sets the orientation of an object using Euler angles
Sets the position of an object in world or local coordinates
Sets the target velocity of a joint motor
Saves the current scene to a file in the configured scenes directory
Starts the simulation
Reads the last proximity sensor detection from the simulation step
Lists all objects in the scene, optionally filtered by type
Gets a single object by path and returns its properties
Stops the simulation
Advances the simulation by one time step
Parameter constraints not fully specified in descriptions. E.g., 'posicion' is an array but no min/max bounds stated; 'alcance' (range) has no units or limits; 'apertura' (angle) should specify radians vs degrees.
Descriptions for sensor tools (comprobar_sensor_proximidad, leer_sensor_proximidad) are vague about the difference between 'on demand' and 'last detection from simulation step'. LLMs may conflate them.