carmaker-mcp

Overview Schema Source Related Servers Discussions Admin

Start the simulation

cm_start_sim

Start a loaded CarMaker test run and return once it is running; if the Simulink model fails to compile, it stops immediately with the error.

Instructions

Start the loaded test run. Returns once it is running; fails at once, with Simulink's error, if the model does not compile. Then call cm_wait_end until it reports finished.

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

Input Schema

Name	Required	Description	Default
`save`	No	save: write a result file (GUI storage mode becomes 'Save all', cm_revert_all puts it back). collect: buffer only. keep: leave the GUI setting alone	save
`speed`	No	x real time; omit for CarMaker's maximum. Slower only if the user asks
`save_logs`	No	Also save what Simulink logged in this run to a MAT file next to the result file (a Simulink Dataset, for MATLAB; for Python call cm_model_logs_save(format='struct', file=...)); cm_wait_end returns logs_file and logs_signal_names
`start_timeout_s`	No	How long the start may take (a Simulink model may compile first)

Output Schema

Name	Required	Description	Default
`note`	No
`state`	No
`popups`	No
`after_s`	No
`started`	No
`save_mode`	No
`matlab_folder_restored`	No
`carmaker_project_restored`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.3.0Nov 2, 2026

changedInput schema / properties / save_logs / description

Previous value: -"Also save what Simulink logged in this run to a MAT file next to the result file, as cm_model_logs_save does; cm_wait_end returns it as logs_file"New value: +"Also save what Simulink logged in this run to a MAT file next to the result file (a Simulink Dataset, for MATLAB; for Python call cm_model_logs_save(format='struct', file=...)); cm_wait_end returns logs_file and logs_signal_names"

addedInput schema / properties / speed

Added value: +{
+  "anyOf": [
+    {
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "x real time; omit for CarMaker's maximum. Slower only if the user asks"
+}

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"
+}
```

Changed2 schema fields changedv0.2.0Oct 12, 2026

addedOutput schema / properties / carmaker_project_restored

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "type": "object"
+}

addedOutput schema / properties / matlab_folder_restored

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "type": "object"
+}

First observedv0.1.0Oct 7, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations establish the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds genuinely non-obvious behavior: it returns as soon as the run is up, and it fails immediately with Simulink's own error if compilation fails rather than hanging. That failure semantics is the key trait an agent needs and it is not derivable from annotations or schema.

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 sentences, zero filler, with the primary action and the failure mode front-loaded before the continuation instruction. Every clause carries information the agent needs.

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 annotations, a full schema, and an output schema present, the description covers the essential lifecycle (start → succeed/fail fast → cm_wait_end). Minor gaps remain: no statement about calling it when a run is already active, and no mention of the start_timeout_s implications on a slow compile, but nothing critical 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%, with each of the four parameters carefully documented in the schema itself (save modes, speed semantics, save_logs side effects, start timeout). The description adds no further parameter 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+resource ("Start the loaded test run") and makes the precondition — the run must already be loaded — explicit, which separates it from cm_load_testrun. It does not distinguish itself from adjacent starters like cm_study_start or cm_standalone_launch, so sibling differentiation is only partial.

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?

"Then call cm_wait_end until it reports finished" gives an explicit, actionable follow-up routing rule that an agent would otherwise have to infer. It stops short of naming when not to call it (already running, standalone sessions) or pointing at cm_stop_sim for the inverse operation.

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

Deploy Server