TSUNAGI///Matrix — MAPPING

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 agent knows this is a safe, non-mutating, closed-domain read. The description adds that the result is descriptive overview content rather than live vehicle data, but says nothing about what it actually returns or how it should inform follow-up calls.

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

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

One sentence, front-loaded with the identity of the resource before the list of topics. It is dense with unexplained proper nouns (WORKS, MILE, MESH) and reads as a run-on list, but nothing is redundant with structured fields.

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

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

With zero parameters and no output schema, the description carries the burden of saying what the call yields, and it does enumerate the topics covered. It stops short of indicating the response shape (prose vs. structured) or the constraints on using that knowledge, but it is adequate for a simple informational tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is empty, so there is nothing to document and the baseline is 4. The description correctly implies a parameterless, self-contained lookup.

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

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

The description spells out the subject matter: an orientation lookup for TSUNAGI///Matrix covering BMW E46 M3 / S54 / MSS54HP / SMG II tooling, the available calculations, which app applies a result to the car, and how WORKS builds and MILE on MESH operate. That clearly separates it from action siblings like read_bin or propose_ve. It is a content outline rather than a verb+resource statement, and the jargon is undefined, which keeps it from a 5.

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

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

The closing directive 'Call this before recommending the apps' gives an explicit ordering rule an agent can act on. It does not state when this tool is unnecessary (e.g., when the user already names a specific app) or map other conditions to siblings, so no exclusion guidance.

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

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

Annotations already declare a safe read (readOnlyHint true, destructiveHint false, closed world), and the description usefully adds that the tool is experimental, returns values only, and does not produce a file — a real behavioral trait beyond the annotations. It stops short of describing cost, limits, or failure modes on bad BIN/log input.

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

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

Two dense sentences that lead with the vehicle/ECU context and the concrete output, then the experimental caveat. Every clause carries information, though the first sentence is packed with parentheticals.

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

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

With no output schema, the description must convey returns, and it does: the rf_korr table plus per-cell evidence, values only, no file emitted. Missing only format/units detail for the returned values, which is minor for a preview tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: the log must contain exhaust temperature, and the BIN must be the MSS54HP calibration partial. That qualifies the otherwise generic file-object parameters.

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

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

States a specific verb (propose) and resource (rf_korr table / KF_RF_KORR_DRREL) plus the exact inputs it derives from (DME image and a drive log with exhaust temperature). It is clear on its own, but it does not differentiate itself from the sibling propose_ve, which follows the same propose-from-files pattern.

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

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

The 'experimental in the app; values only — the WORKS build of TUNER makes the file' line hints at when this preview-only tool is appropriate, and use_sample implies a no-files-yet path, but no explicit when-to-use/when-not or alternative (e.g. vs propose_ve) is named.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the output is derived map values ('which cells change and by how much, which need more driving and how') and that no BIN is produced here. It does not discuss caching, rate limits, or result format details, keeping it just short of 5.

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

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

Two dense sentences that front-load the domain and the input-to-output relationship; the second sentence handles differentiation and scoping cleanly. The phrasing is heavy with domain jargon and punctuation (alpha-N, ///, 0x-style naming), which slows parsing slightly, but no clause is wasted.

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

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

With no output schema, the description carries the burden of describing return content, and it does: the cells that change, the magnitude of change, and which regions need more driving data. Together with the schema it tells an agent everything needed to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with bin_file, log_file, and use_sample fully described in the schema, so the baseline is 3. The prose reinforces that both a DME image and a drive log are required together ('from the same two files') but adds no syntax or format detail beyond the schema.

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

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

States a specific verb (propose) and resource (VE / alpha-N map correction) scoped to a precise domain (BMW E46 M3 S54 MSS54HP CSL conversion), and describes the inputs (DME image + drive log) that drive it. It also differentiates itself from the sibling propose_rfkorr by naming 'VE (alpha-N) map' and from the external tuner, so an agent can tell what this tool produces.

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

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

Explicitly frames the tool's role: 'Values only here; the free MSS54HP CSL CONVERT /// TUNER makes the tuned BIN from the same two files' — telling the agent to call this for advisory map values rather than a finished BIN, and that the same inputs feed the downstream tool. It lacks an explicit 'do not use when...' for the read_* siblings, but the context is clear.

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

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 genuine value beyond that by disclosing exactly what the operation reports (checksums, logic patches MAP/TANK VENT/WOT TH/RF GATE, VE and warm-up table deltas from stock, VE table), which tells the agent the observable outcome.

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

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

It is a single dense sentence that front-loads the platform and the core action, then lists the reported artifacts. Nothing is redundant, though the packed jargon makes it slightly hard to parse and it could be split for readability.

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

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

With no output schema, the description carries the burden of explaining return values, and it does so by naming the checksums, patch set, table-distance measurements and VE table it reports. Given the nested-object parameter is documented in the schema, this is largely complete, missing only preconditions for a valid BIN.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the nested bin_file object and the use_sample flag, so the schema documents both parameters fully. The description adds no parameter syntax or format detail beyond what is already in the schema, so the baseline of 3 is appropriate.

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

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

The description gives a specific verb ('read') and resource ('a 64 KB calibration partial') scoped to a precise domain (BMW E46 M3/S54 MSS54HP), and enumerates what it reports. It does not explicitly distinguish itself from the smg2_* or propose_* siblings, so an agent must infer the boundary from the platform name rather than being told.

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

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

There is no statement of when to use this tool versus alternatives such as propose_ve, propose_rfkorr, or smg2_read. The only usage signal is the domain context (CSL conversion) and the schema's use_sample flag, which lives outside the description. No prerequisites or exclusions are stated.

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

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

Annotations already establish readOnly/non-destructive/closed-world, so the bar is lower. The description still adds real behavioral value: it discloses that the tool reasons about which rows the VE and rf_korr calculations can consume and returns remediation advice per excluded row, and that the BIN supplies DME-specific lambda thresholds.

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

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

Front-loaded with the domain and action, followed by the report contents and the BIN caveat. Dense but every clause earns its place; no filler or restatement of the title.

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

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

With no output schema, the description does the work of describing the return content (channels, usable-row counts, exclusion reasons with fixes). Together with full schema coverage on the nested file objects, an agent has enough to call it correctly; only the concrete output shape is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema does not: bin_file exists to source the DME's own lambda thresholds, and use_sample selects a practice BIN/drive rather than user files.

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

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

States a specific verb (read), resource (an MSS54HP drive log), and the exact output content: channels, usable-row counts for VE and rf_korr, and exclusion reasons. This is clearly distinguishable from sibling tools like read_bin, propose_ve, or about_matrix.

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

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

Gives clear context for use (Testo or TUNER CSV drive logs) and explains the practice-mode alternative via use_sample ('before the owner has files'), plus when to attach the BIN. It stops short of explicit when-not-to-use guidance or routing against siblings like propose_ve.

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

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 read-only safety profile is covered structurally. The description adds the implicit constraint that the two images must be the same scope, which is real behavioral context, but says nothing about computational cost, failure modes, or what happens when scopes mismatch. With annotations doing the heavy lifting, a 3 is appropriate.

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

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

A single compact sentence-pair that front-loads the platform context and then the three comparison outputs. Every clause carries content, though the headline-style noun phrase is slightly clipped and could read more cleanly as a sentence.

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

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

There is no output schema, so the description correctly carries the return semantics itself, naming the three results (differing items, cell count, largest difference). Given a 3-parameter nested-object tool, this is nearly sufficient; a note on how differences are defined (byte vs scaled value) would close the remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67% and the schema itself explains xdf_file (which .xdf variant per read size) and image_file (24 KiB window vs 512 KiB full flash), so the baseline is 3. The description adds only the 'same scope' constraint tying image_file and other_file together, and never mentions xdf_file, whose role in the comparison is non-obvious. No meaningful compensation for the uncovered portion.

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

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

The description names a specific verb+resource (compare two SMG II calibrations) and enumerates what the comparison yields: differing items, cell counts, and largest difference. This clearly separates it from read_oriented siblings like smg2_read and smg2_image. It stops short of naming any sibling by name, so it is not fully self-differentiating.

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

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

The phrase 'two images of the same scope' implies a precondition (both files must be the same read scope), which is the only usage guidance offered. There is no explicit statement of when to use this versus smg2_read or smg2_image, and no exclusions or alternatives are named. Usage 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.

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 genuine behavioral value by disclosing what is reported (image class, ZB number, CRC check results) and the accepted image shapes, but says nothing about failure modes, permissions, or limits.

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

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

A single dense sentence front-loads the platform context well, but the closing fragment 'Needs no definition' is opaque and does not earn its place, weakening an otherwise compact layout.

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

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

With no output schema, the description usefully previews the return content (image class, ZB number, CRC validity). Given the nested image_file object and closed-world read-only nature, an agent has enough to call it correctly, though selection guidance against siblings remains missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and image_file's own description plus use_sample's description already document both parameters. The description's mention of the 24 KiB calibration window and 512 KiB flash echoes the schema's nesting description rather than extending it, so the baseline 3 applies.

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

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

The description names a specific verb ('say what an image is') and a concrete resource (BMW E46 M3 SMG II / Siemens SMG2 510 ECU image), and enumerates the outputs: image class (24 KiB calibration window vs 512 KiB flash), ZB number, and CRC integrity. It is clearly distinguishable from read/compare siblings, though it never names them explicitly.

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

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

There is no statement of when to use this versus smg2_read, smg2_compare, or read_bin. The trailing 'Needs no definition' is cryptic and does not function as usage guidance. An agent must infer the selection criteria from the name alone.

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

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.

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.

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.

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.

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.

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.