carmaker-mcp

Overview Schema Source Related Servers Discussions Admin

Stop the simulation

cm_stop_sim

Destructive

Stops a running IPG CarMaker simulation and optionally waits up to a set time for it to become idle, returning wait-end status when requested.

Instructions

Stop the running simulation. With wait_s > 0 it returns what cm_wait_end returns.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "cm_stop_sim"
  }
}

Input Schema

Name	Required	Description	Default
`wait_s`	No	Wait this long for the simulation to become idle (0: do not wait)

Output Schema

Name	Required	Description	Default
`live`	No
`note`	No
`state`	No
`popups`	No
`testrun`	No
`finished`	No
`waited_s`	No
`elapsed_s`	No
`logs_file`	No
`distance_m`	No
`end_status`	No
`log_errors`	No
`logs_error`	No
`sim_time_s`	No
`poll_errors`	No
`result_file`	No
`log_warnings`	No
`simulink_error`	No
`stop_requested`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.2Oct 19, 2026
- addedOutput schema / properties / log_warnings
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
```
Changed3 schema fields changedv0.2.1Oct 16, 2026
- addedOutput schema / properties / popups / items / properties / closed
```
Added value: +{
+  "type": "boolean"
+}
```
- addedOutput schema / properties / popups / items / properties / details
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / popups / items / properties / program
```
Added value: +{
+  "type": "string"
+}
```
First observedv0.1.0Oct 7, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a state-changing operation. The description adds the wait/return-equivalence behavior but does not say what is lost on stop, whether results survive, or how long it blocks by default.

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?

Two short sentences, action first, conditional behavior second. Nothing wasted and nothing buried.

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?

With an output schema present and annotations covering the destructive profile, the description is nearly complete for a one-parameter stop tool. It only omits edge-case behavior, such as calling it when no simulation is active.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the wait_s description already documents the wait-for-idle semantics. The description goes beyond the schema by tying wait_s > 0 to returning the same payload as cm_wait_end, which clarifies the parameter's effect on the response.

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?

States a specific verb and resource ('Stop the running simulation'), making the opposite of cm_start_sim immediately obvious. It references cm_wait_end only for return-value equivalence, so sibling differentiation is implicit rather than spelled out.

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 wait_s > 0 clause implies you can use this in place of a separate cm_wait_end call, which is useful implied guidance. However, it never says when to prefer this over other termination paths such as cm_study_cancel or cm_standalone_control, nor what happens if no simulation is running.

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

Deploy Server