Skip to main content
Glama
Sign In
carmaker-mcp

carmaker-mcp

by dimitr-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Read a project data file

cm_read
Read-only

Reads CarMaker infofile key/value pairs 300 at a time, with key, prefix, or search filters and offset paging for targeted project data.

Instructions

Key / value pairs of a CarMaker infofile, 300 at a time: filter by keys, prefix or search, or page with offset. For a test run first driver (its template or 'TestRun', knowledge, main limits) and, also for a vehicle, standalone: false names the vehicle's Simulink parts (runs need the MATLAB session).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>",
      "name": "<name>"
    },
    "name": "cm_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
keysNoOnly these keys
kindYesKind of project data; selects the folder below <project>/Data
nameYesFile name relative to the kind's folder, as cm_list returns it
offsetNoSkip this many keys (paging: next_offset)
prefixNoOnly keys starting with this, e.g. 'Vehicle' or 'DrivMan.'
searchNoOnly keys containing this, any case, e.g. 'Control.Kind'

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.0
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "Skip this many keys (paging: next_offset)",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / search
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Only keys containing this, any case, e.g. 'Control.Kind'"
+}
  2. First observedv0.1.0

TDQS

B3.3/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. The description usefully adds the 300-key page size and the fact that `standalone: false` names the vehicle's Simulink parts and requires a MATLAB session, but the second sentence is grammatically tangled and could be misread, blunting the added value.

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

Conciseness3/5

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

Two sentences with no filler, and the core read/paging behavior is front-loaded. However the second sentence crams `driver`, template, 'TestRun', knowledge, main limits, `standalone` and MATLAB into one clause chain, which reads as under-edited rather than concise.

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

Completeness3/5

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

With an output schema present, return values need not be explained, and annotations cover the read-only profile. What is missing is a clear statement of the relationship to cm_list (which produces the `name` this tool consumes) and a legible version of the driver/standalone prerequisite note, so the definition is adequate but not complete.

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 all six parameters are already documented, including prefix/search examples and the next_offset paging hint. The description only adds the page-size constant (300), which is a modest supplement rather than meaning the schema lacks.

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?

The description names a specific resource and scope: key/value pairs of a CarMaker infofile returned 300 at a time with key/prefix/search filtering and offset paging. It is not phrased as a verb+object sentence (that is left to the title) and it does not contrast itself with near siblings like cm_list or cm_model_get, but the operation is identifiable from the text alone.

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?

It gives implied usage guidance through the filter/paging options and a domain hint about reading `driver` first for a test run, but the sentence about `driver`/`standalone` is cryptic and does not state when to choose cm_read over cm_list (enumerate files) or cm_model_get (model data). The agent must infer the selection rule.

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

Deploy Server

Other Tools