Skip to main content
Glama
carmaker-mcp
by dimitr-io

Take a picture in IPGMovie

cm_movie_snapshot

Captures an image of IPGMovie’s 3D view during or after a CarMaker run, or replays a saved result file to show vehicle motion at a chosen time.

Instructions

A picture of IPGMovie's 3D view, returned as an image. After a run it shows any moment of the last run (time_s), provided IPGMovie was open during that run. During a run, without time_s, it shows the IPGMovie window as it is at that moment (in the window's own size). With erg it replays a saved result file, which must hold the vehicle's motion (cm_output_quantities_edit(preset='movie') before that run). Do not pass time_s during a run: that makes IPGMovie stop following the run. Needs the MATLAB session's IPGMovie (cm_movie_open); a standalone IPGMovie (movie=true) has no pictures.

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

Input Schema

NameRequiredDescriptionDefault
ergNoReplay this result file instead of the last run (absolute path, or relative to the project)
widthNoPicture width in pixels (not during a run)
cameraNoCamera view: 'DEFAULT', "Bird's Eye View", 'Left Side', 'Right Side', 'Sitting In Vehicle (A)', or one from the project (default: keep the view)
heightNoPicture height in pixels (not during a run)
time_sNoSimulation time of the picture in s (default: the latest moment IPGMovie holds)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations are thin (readOnly=false, destructive=false, openWorld=false), and the description carries the real behavioral weight: passing time_s during a run causes IPGMovie to stop following the run, a genuine side effect not encoded anywhere else. It also names the required session dependency (cm_movie_open) and the failure mode for standalone IPGMovie.

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 the outcome, then mode-by-mode guidance; every sentence carries information. The erg clause is slightly nested and telegraphic, but nothing is redundant 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?

No output schema exists, yet the description states the return is an image and whether it reflects a live or replayed state. Combined with precondition, exclusion, and dependency coverage, an agent has everything needed to call it correctly.

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?

With 100% schema coverage, the baseline is 3, but the description adds cross-parameter semantics the schema cannot: time_s interacts with run state, and width/height are ignored during a run ("(not during a run)" appears in both schema and description). It does not restate the camera enum values, correctly leaving that to the schema.

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?

Opens with a specific verb+resource: "A picture of IPGMovie's 3D view, returned as an image." It implicitly distinguishes itself from cm_results_plot and cm_movie_open by describing the source (live 3D view / replayed erg) and output type, so an agent can select it without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly partitions the three usage modes: post-run with time_s, during-run without time_s, and erg replay. It also states a hard exclusion ("Do not pass time_s during a run") and a precondition for erg (result file must hold motion, set via cm_output_quantities_edit(preset='movie')).

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