carmaker-mcp

Overview Schema Source Related Servers Discussions Admin

Wait for the simulation to end

cm_wait_end

Read-only

Wait for an IPG CarMaker simulation to finish or report live status, returning end results, log warnings/errors, or a prompt to call again until idle.

Instructions

Wait until the simulation is idle again. finished=true: end status, simulation time and distance, result_file, new log errors and warnings (settings CarMaker ignored show up there) and pop-ups. finished=false: current state and live values; call again to keep waiting.

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_wait_end"
  }
}

Input Schema

Name	Required	Description	Default
`poll_s`	No	Seconds between status polls
`timeout_s`	No	Longest time to wait in s, at most 50 (larger values are cut to 50); call again if not finished

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.3.0Nov 2, 2026

changedInput schema / properties / timeout_s / description

Previous value: -"Longest time to wait in seconds; keep it below your client's tool time-out and call again if not finished"New value: +"Longest time to wait in s, at most 50 (larger values are cut to 50); call again if not finished"

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.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. Beyond that, the description does add value by disclosing the two result shapes and that ignored CarMaker settings surface as log warnings – genuinely useful behavioral context – but it omits blocking behaviour and how it differs from the standalone wait sibling.

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

Conciseness4/5

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

Front-loads the purpose in the first clause, then enumerates the two return states compactly. The parenthetical about CarMaker settings is a slight detour but still earns its place as actionable signal.

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?

For a blocking wait tool with full schema coverage and an output schema, the description covers the essential loop semantics and the poll-again contract. It could be stronger by tying the timeout cap to the retry instruction, but nothing critical for correct invocation is missing.

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 description coverage is 100%, so both poll_s and timeout_s are already fully documented, including the 50s cap. The description adds no parameter-level meaning, so the baseline of 3 applies.

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: wait until the simulation is idle again, and names the two outcome states (finished=true/false) an agent will encounter. It is clear what the tool does, but it does not distinguish itself from close siblings such as cm_standalone_wait_end, cm_study_wait, or cm_status.

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

Usage Guidelines4/5

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

Gives usable loop guidance – 'call again to keep waiting' when finished=false – which tells the agent how to keep polling rather than abandoning the tool. It stops short of naming alternatives (e.g. cm_status for a non-blocking peek) or saying when this tool is the wrong choice.

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

Deploy Server