carmaker-mcp

Overview Schema Source Related Servers Discussions Admin

Start the simulation

cm_start_sim

Start a loaded test run and return once it is running; if the Simulink model fails to compile, it stops immediately with the compile error. Then call cm_wait_end to wait for completion.

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.

Input Schema

TableJSON 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
`save_logs`	No	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
`start_timeout_s`	No	How long the start may take (a Simulink model may compile first)

Output Schema

TableJSON 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.

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

Behavior4/5

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

Annotations declare a non-destructive, closed-world write, and the description adds genuinely useful behavior beyond them: the call returns once running, and fails immediately with Simulink's own compile error. That failure-mode and timing detail is what an agent cannot infer from the schema or annotations.

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 tight sentences, front-loaded with the primary action, then the failure condition and the required follow-up call. No filler.

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 start tool with a full output schema, the description covers the essential lifecycle: it starts, it may fail fast, and the agent must poll cm_wait_end. Only a note on prerequisites (test run already loaded via cm_load_testrun) 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 the save enum, save_logs, and start_timeout_s all documented in the schema itself. The description adds no parameter-level meaning beyond this, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action on a specific resource ('Start the loaded test run'), and the phrasing 'loaded test run' implicitly distinguishes it from startup siblings like cm_study_start or cm_standalone_launch.

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 explicit next-step guidance ('Then call cm_wait_end until it reports finished'), which is exactly what an agent needs after starting. It does not, however, state when not to use this tool or contrast it with cm_study_start/cm_standalone_launch alternatives.

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