Modify the physics engine properties and dynamics step size of the CoppeliaSim scene. Stop the simulation to update these core parameters.
Inspect or set the scene physics engine property and dynamics step size. Changes require simulation stopped; engine_property is [index, version].
| Name | Required | Description | Default |
|---|---|---|---|
| headless | No | ||
| engine_property | No | ||
| dynamics_step_size | No |
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations were provided, the description carries the full burden of behavioral disclosure. Stating that the simulation must be stopped to make changes is a major behavioral constraint that would otherwise be unknown to the agent.
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 description is a single, highly efficient sentence that front-loads the core purpose while placing necessary constraints and hints at the end. There is no superfluous language.
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?
Given the complete lack of structured metadata (0% schema coverage, no annotations), the description is exceptionally complete, covering functionality, required state for changes, and data format hints for complex parameters.
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?
With 0% schema description coverage, the description provides vital semantic information. It defines the format of the 'engine_property' argument as '[index, version],' guiding the agent on how to structure this specific input.
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 description clearly and specifically states the function (Inspect or set) and the resource it acts upon (scene physics engine property and dynamics step size). It distinguishes its purpose as a configuration tool, distinct from general simulation or catalog tools.
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 provides a critical precondition for modification: 'Changes require simulation stopped.' This is a vital usage guideline that prevents agents from attempting mutations that would fail at runtime.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.