Skip to main content
Glama

TSUNAGI///Matrix — MAPPING

Decode an SMG II calibration

smg2_read
Read-only

BMW E46 M3 SMG II (Siemens SMG2 510): decode the calibration — shift speed thresholds per gear and program, gear ratios, clutch and launch settings — through the owner's MS4X definition with E46M3SMG2 /// MAPPING's corrections. Pass item for one item's full table and axes.

Input Schema

NameRequiredDescriptionDefault
itemNoA uniqueId (e.g. 0x7695) or words of a title (e.g. "A1 Speed").
xdf_fileYesThe MS4X definition: Siemens_SMG_II_510_24K.xdf for a window, _512K.xdf for a full read. It is MS4X's and the owner's own.
image_fileYesAn SMG II 510 image: the 24 KiB calibration window or the 512 KiB full flash.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds provenance value (MS4X definition plus E46M3SMG2 /// MAPPING corrections) but says nothing about return format, pagination, or failure modes when image and definition size mismatch.

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?

Two dense sentences, front-loaded with the target ECU and calibration scope, with the item-parameter tip last. Efficient, though the jargon-heavy enumeration makes it slightly harder to scan than a clean 5.

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?

For a read-only decoder with no output schema and full schema descriptions on all three parameters, the description covers what is decoded and the source of the corrections. It leaves the no-item case (full decode?) unstated, which is the one remaining gap.

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 100%, so the baseline is 3, but the description genuinely adds meaning: passing 'item' yields one item's full table plus axes, which tells the agent what the selector changes rather than merely restating the schema's uniqueId/title wording.

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?

Names a specific verb (decode) and resource (SMG II / Siemens SMG2 510 calibration), and enumerates the content decoded: shift-speed thresholds per gear and program, gear ratios, clutch and launch settings. It does not, however, distinguish itself from siblings like smg2_image or smg2_compare, so it stops short of a 5.

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?

The only usage guidance is 'Pass item for one item's full table and axes,' which implies the selector behavior but never states when to use this tool rather than smg2_image, smg2_compare, or read_bin, nor any prerequisites for the required xdf_file/image_file pair.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.