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

Read a section of the guide

cm_guide
Read-only

Retrieve IPG CarMaker guidance by topic for sessions, parameters, and test runs; omit the topic to list available guide sections.

Instructions

A section of this server's guide (the same text as the resource carmaker://guide).

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

Input Schema

NameRequiredDescriptionDefault
topicNoe.g. 'ipgdriver', 'driver', 'parameters'; none lists the topics

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

C2.9/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 adds one genuinely useful behavioral fact — the output is identical to the carmaker://guide resource — but says nothing about section granularity, size, or what happens for an unknown topic (the has-output-schema field covers the format).

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?

One short sentence with no padding, and the resource equivalence is placed up front in a parenthetical. It is efficient, though the fragmentary phrasing means brevity comes partly at the cost of grammatical clarity.

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?

The tool is trivial (zero required params, output schema present) so return-value detail is unnecessary, but for a documentation-lookup entry point an agent would benefit from knowing which topics exist and when to reach for it. That guidance is entirely absent.

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% and the schema itself explains the topic parameter with examples ('ipgdriver', 'driver', 'parameters') and the null default. The description adds nothing further; baseline 3 applies since the schema does all the work.

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

Purpose3/5

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

The description is a bare noun phrase ('A section of this server's guide') with the verb only implied from the title 'Read a section of the guide'. The purpose is inferable and no sibling tool serves guide text, so an agent can place it, but the description on its own never states that it returns/reads content.

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

Usage Guidelines2/5

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

No when-to-use guidance: nothing says to consult this before calling cm_read/cm_edit, nor when to pass a topic vs. omit it. The only implicit hint is that the same text is available as the resource carmaker://guide, which suggests an alternative channel but is not framed as usage advice.

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