mib2c-mcp

Overview Schema Source Related Servers Discussions Admin

Replace images

replace_images

Replaces multiple images at once by matching picture file names to image paths within a scope, skips unmatched or ambiguous files, and keeps changes unsaved until saved.

Instructions

Replaces several images at once from picture files on this computer, each matched by its file name to the image of that name whose path contains scope (such as "0204080200/GenericCarAdjuster/AmbianceLight/" or a car code). A file that matches no image, or several different ones, is skipped and listed; an image shared by several cars counts once. Unsaved until save.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "scope": "<scope>"
    },
    "name": "replace_images"
  }
}

Input Schema

Name	Required	Description
`fit`	No
`files`	No	Or these files
`scope`	Yes	Part of the image paths to look in (a car code, or a folder of it)
`folder`	No	Every .png / .jpg / .webp in this folder

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 7, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that sources are local files on the machine, that unmatched or ambiguously matched files are skipped and reported, that an image shared across cars counts once, and critically that changes are 'Unsaved until save'. It does not mention whether prior images are recoverable (a revert_image sibling exists) or any permission constraints.

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?

Dense but front-loaded: the core action and the matching rule come first, followed by edge-case handling and the save requirement. The parenthetical example earns its place; the sentence is long and could be split for readability, but there is little wasted content.

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 mutation tool with no annotations and no output schema, the description covers the essential semantics: matching rule, skip/ambiguity behavior, deduplication, and persistence. The main gaps are the unexplained fit parameter and what is returned (whether the 'listed' skipped files are part of the response or surfaced elsewhere).

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 coverage is 75%, and the description adds real meaning for scope (a path substring, e.g. a car code or folder fragment) and for the file-name-to-image matching rule. However, the fit enum (exact/fit/fill/stretch) is never explained, and the interaction between files and folder (mutually exclusive alternatives) is only hinted at by the schema wording 'Or these files'.

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 with scope: 'Replaces several images at once from picture files on this computer'. The 'several ... at once' phrasing implicitly distinguishes it from the singluar sibling replace_image, though it never names that sibling 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?

Usage context is implied through the matching mechanics (file name matched to image path containing scope, with a concrete example path), but there is no explicit statement of when to choose this over replace_image, revert_image, or list_images, and no prerequisites given.

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