carmaker-mcp

Overview Schema Source Related Servers Discussions Admin

Start a parameter study

cm_study_start

Runs one test run repeatedly in the background with different Key, workspace, and driver parameter values, returning a study ID to wait on. Finds which values actually change results.

Instructions

Run one test run several times with different parameter values, one after another, in the background. Returns a study id at once; wait with cm_study_wait. Nothing is written to project files. The answer names values that will change nothing: keys_not_found, workspace_not_found and workspace_overruled (use scope=); Driver.* keys that a driver template overrides are refused (use 'driver'). Rows give valid and wall_s, the clock time of the run. A study stops at the first run that finds no CarMaker licence.

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

Input Schema

Name	Required	Description	Default
`grid`	No	Every combination of value lists, added to variations: {'driver': {'Driver.Acc.ayMax': [12, 14]}, 'driver_scale': {'Driver.Acc.GGExp': [1, 2, 4]}, 'keys': {...}, 'workspace': {...}}. driver_scale multiplies the driver's own value (a table: all but its first column). At most 100 runs
`keys`	No	Keys for every run, e.g. {'Vehicle': 'Car_B'}; a variation's own keys win
`mode`	No	cm4sl: the MATLAB-connected session. standalone: CarMaker without MATLAB (no 'workspace' values). auto: cm4sl if MATLAB is connected	auto
`gates`	No	'markers': each row gets 'sectors', the times CarMaker's lap timing takes at the test run's trigger point markers, each from the last reference marker (a lap on a skid pad). Or road positions in m: 'splits', the times between them
`movie`	No	mode standalone: show the runs in IPGMovie
`rerun`	No	Runs of an earlier study again: {'study': id, 'labels': ['best']}, e.g. with movie and keep_open to show the best run; an IPGMovie window kept open is reused
`scope`	No	'base' for the MATLAB base workspace, or the name of a loaded Simulink model for that model's workspace	base
`speed`	No	x real time; omit for CarMaker's maximum. Slower only if the user asks
`testrun`	No	Test run relative to Data/TestRun (with rerun: default its study's)
`keep_open`	No	With movie: leave the last run in IPGMovie (close it with cm_standalone_close)
`max_run_s`	No	A run is stopped after this wall time in s
`save_logs`	No	After every run, save what Simulink logged and the workspaces as that run used them to a MAT file next to its result file (mode cm4sl; logs_file per row)
`close_open`	No	standalone: first close the CarMaker programs this server left open (each holds a licence)
`quantities`	No	Quantities to summarise per run (default: Time, Car.v). Standalone they are also all its result file stores, besides what timing needs: list every quantity to plot later
`variations`	No	One entry per run: {'label': 'heavy', 'keys': {'Body.mass': 320}, 'workspace': {'Kp_yaw': 1.5}, 'driver': {'Driver.Acc.ayMax': 14, 'Driver.Acc.GGExp': '10 1.5 1.5\n90 5 5'}}. 'keys': infofile keys in memory for that run; 'workspace': MATLAB variables in 'scope', restored after the run; 'driver': driver template values, in a copy deleted after the run. All optional

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed24 schema fields changedv0.3.0Nov 2, 2026

addedInput schema / properties / close_open

Added value: +{
+  "default": false,
+  "description": "standalone: first close the CarMaker programs this server left open (each holds a licence)",
+  "type": "boolean"
+}

addedInput schema / properties / gates

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    {
+      "const": "markers",
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "'markers': each row gets 'sectors', the times CarMaker's lap timing takes at the test run's trigger point markers, each from the last reference marker (a lap on a skid pad). Or road positions in m: 'splits', the times between them"
+}

addedInput schema / properties / grid

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "additionalProperties": {
+          "items": {},
+          "type": "array"
+        },
+        "type": "object"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Every combination of value lists, added to variations: {'driver': {'Driver.Acc.ayMax': [12, 14]}, 'driver_scale': {'Driver.Acc.GGExp': [1, 2, 4]}, 'keys': {...}, 'workspace': {...}}. driver_scale multiplies the driver's own value (a table: all but its first column). At most 100 runs"
+}

addedInput schema / properties / keep_open

Added value: +{
+  "default": false,
+  "description": "With movie: leave the last run in IPGMovie (close it with cm_standalone_close)",
+  "type": "boolean"
+}

addedInput schema / properties / keys

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Keys for every run, e.g. {'Vehicle': 'Car_B'}; a variation's own keys win"
+}

changedInput schema / properties / mode / default
```
Previous value: -"cm4sl"New value: +"auto"
```

changedInput schema / properties / mode / description

Previous value: -"cm4sl: the MATLAB-connected session. standalone: a separate CarMaker process per run (no 'workspace' values)"New value: +"cm4sl: the MATLAB-connected session. standalone: CarMaker without MATLAB (no 'workspace' values). auto: cm4sl if MATLAB is connected"

changedInput schema / properties / mode / enum

Previous value: -[
-  "cm4sl",
-  "standalone"
-]New value: +[
+  "auto",
+  "cm4sl",
+  "standalone"
+]

addedInput schema / properties / movie

Added value: +{
+  "default": false,
+  "description": "mode standalone: show the runs in IPGMovie",
+  "type": "boolean"
+}

changedInput schema / properties / quantities / description

Previous value: -"Quantities to summarise per run (default: Time, Car.v)"New value: +"Quantities to summarise per run (default: Time, Car.v). Standalone they are also all its result file stores, besides what timing needs: list every quantity to plot later"

addedInput schema / properties / rerun

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Runs of an earlier study again: {'study': id, 'labels': ['best']}, e.g. with movie and keep_open to show the best run; an IPGMovie window kept open is reused"
+}

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

addedInput schema / properties / testrun / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / testrun / default
```
Added value: +null
```

changedInput schema / properties / testrun / description

Previous value: -"Test run relative to Data/TestRun"New value: +"Test run relative to Data/TestRun (with rerun: default its study's)"

removedInput schema / properties / testrun / type
```
Removed value: -"string"
```

addedInput schema / properties / variations / anyOf

Added value: +[
+  {
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "maxItems": 100,
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / variations / default
```
Added value: +null
```

changedInput schema / properties / variations / description

Previous value: -"One entry per run: {'label': 'heavy', 'keys': {'Body.mass': 320}, 'workspace': {'Kp_yaw': 1.5}}. 'keys' are infofile keys applied in memory for that run only (prefix a place such as 'Vehicle:' if needed); 'workspace' are MATLAB variables in 'scope', restored after the run. Both are optional"New value: +"One entry per run: {'label': 'heavy', 'keys': {'Body.mass': 320}, 'workspace': {'Kp_yaw': 1.5}, 'driver': {'Driver.Acc.ayMax': 14, 'Driver.Acc.GGExp': '10 1.5 1.5\\n90 5 5'}}. 'keys': infofile keys in memory for that run; 'workspace': MATLAB variables in 'scope', restored after the run; 'driver': driver template values, in a copy deleted after the run. All optional"

removedInput schema / properties / variations / items

Removed value: -{
-  "additionalProperties": true,
-  "type": "object"
-}

removedInput schema / properties / variations / maxItems
```
Removed value: -50
```
removedInput schema / properties / variations / minItems
```
Removed value: -1
```
removedInput schema / properties / variations / type
```
Removed value: -"array"
```

removedInput schema / required

Removed value: -[
-  "testrun",
-  "variations"
-]

First observedv0.1.0Oct 7, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: asserts nothing is written to project files (consistent with destructiveHint=false), discloses that a study aborts at the first run without a CarMaker licence, and explains which response fields (keys_not_found, workspace_overruled, refused Driver.* keys) mean a value had no effect, with the corrective argument for each.

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-loaded with what it does and how to wait, and every sentence carries information. The prose is telegraphic in places ('Rows give valid and wall_s, the clock time of the run') and could be tightened, but there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-parameter, no-required-arg tool with a full schema and an output schema, the description supplies exactly the missing layer: background/id-return semantics, licence abort behaviour, side-effect scope, and the meaning of diagnostic response keys. No return-format explanation is needed.

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 already 100%, so the baseline is 3; the description adds real cross-parameter guidance not in the schema, namely that workspace_overruled is fixed with scope=<model> and that refused Driver.* keys belong in 'driver'. Other parameters are left entirely to their schema text.

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 verb and resource: runs one test run repeatedly with different parameter values, one after another, in the background, and returns a study id immediately. This is clearly distinct from the single-run siblings (cm_start_sim, cm_live) and the study-control siblings it names (cm_study_wait).

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?

Explicitly routes the agent to cm_study_wait for completion, and the speed parameter notes 'slower only if the user asks', giving a usage norm. It does not explicitly contrast with repeating cm_start_sim or mention cm_study_cancel, so the exclusions are implicit rather than stated.

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

Deploy Server