Skip to main content
Glama
Sign In
carmaker-mcp

carmaker-mcp

by dimitr-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Wait for a standalone run to end

cm_standalone_wait_end
Read-only

Wait for a standalone CarMaker simulation to finish and return simulation time, distance, error flag, and log errors. Call again while unfinished to keep waiting.

Instructions

Wait until the instance's simulation has finished. finished=true: simulation time and distance, error flag and log errors. finished=false: 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_standalone_wait_end"
  }
}

Input Schema

NameRequiredDescriptionDefault
instanceNoStandalone instance id such as 'sa1' (may be omitted while there is only one)
timeout_sNoLongest time to wait in s, at most 50 (larger values are cut to 50); call again if not finished

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • 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"
  2. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered. The description adds real behavioral value beyond that: the tool blocks, returns simulation time/distance plus an error flag and log errors on success, and must be re-invoked on timeout. It omits the 50s timeout cap, but the schema covers that.

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 dense sentences with no filler; the blocking purpose leads and the finished=true/false branching follows in a scannable structure. Every clause carries information.

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?

An output schema exists, so the return-shape summary is bonus rather than necessity, and the polling/timeout behavior is covered. Minor gap: it doesn't say what happens to the simulation after a timeout, or whether the instance remains usable, which matters for a blocking call.

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 instance id format and the timeout cap ('larger values are cut to 50') fully documented in the schema. The description adds no parameter-level meaning, so the baseline 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: waits until the instance's simulation finishes, which is clearly scoped to standalone runs. The 'standalone' qualifier implicitly separates it from cm_wait_end and cm_standalone_status, though it never names those siblings explicitly.

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?

Provides in-loop guidance ('finished=false: call again to keep waiting'), which is useful for the polling pattern. However it never states when to prefer cm_standalone_status (non-blocking check) or cm_wait_end (non-standalone wait) over this tool, so tool selection is left to inference.

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