Skip to main content
Glama
Lecoeurdelest

mujoco-mcp

by Lecoeurdelest
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

mujoco_step

Advance a MuJoCo simulation by multiple physics steps in one call, optionally set persistent actuator controls, and retrieve the resulting state JSON.

Instructions

Advance the simulation. Optionally set actuator controls first; ctrl persists across later steps.

Returns the post-step state JSON: {session_id, time, steps_taken, qpos, qvel, ctrl, sensors, ...}
filtered by `include`. Batch steps in one call (e.g. nsteps=500 for 1s at timestep 0.002)
instead of many single-step calls. Errors and suggests mujoco_reset if the state diverges.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ctrlNoActuator controls: full vector in actuator order, or {actuator_name: value} for a subset. Persists on the session until changed.
nstepsNoPhysics steps to advance; simulated time = nsteps * timestep
includeNoState blocks to return, any of: qpos, qvel, ctrl, sensors, sensors_raw, bodies, contacts (default: qpos, qvel, ctrl, sensors)
precisionNoDecimal places for returned floats
session_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With only four all-false hints in the annotations, the description carries the behavioral burden and delivers: ctrl persistence across subsequent steps, the error-and-suggest behavior ("suggests mujoco_reset if the state diverges"), and the performance characteristic of batching. This is meaningful context beyond the structured annotation fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences with zero filler: the first states the core action, the second the persistence trait, the third the return shape, and the fourth batching plus error recovery. The strongest detail is front-loaded, and every sentence earns its place.

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?

An output schema exists, so return-format details are mostly handled externally, and the description covers the key call patterns (optional ctrl, batched nsteps, include filtering, divergence recovery). The main omission is the relationship to mujoco_step_guarded, which keeps this from being fully complete.

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 80%, so the schema already documents most parameters. The description adds real interpretive value for nsteps (batching to reach a 1s simulation) and include (filtering the returned state), but ctrl persistence is already stated in the schema, and precision is left for the schema to carry. Net addition is modest, matching the baseline.

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?

"Advance the simulation" is a crisp verb+resource statement, and the description further scopes the tool by noting optional control-setting plus the returned state. However, it never distinguishes itself from the near-identical sibling mujoco_step_guarded, so an agent must infer the difference from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete in-tool guidance ("Batch steps in one call... instead of many single-step calls") with a worked example tying nsteps to simulated time. But it does not explicitly say when to choose this tool over alternatives such as mujoco_step_guarded or mujoco_set_state, leaving tool-selection guidance implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools