mib2c-mcp

Overview Schema Source Related Servers Discussions Admin

Export image

export_image

Writes a skin image to a PNG file on your computer for editing in another tool, using a stored path or image index, so you can bring it back later.

Instructions

Writes one image of the skin to a PNG file on this computer (as stored, or its unsaved replacement): to edit it in another tool, then bring it back with replace_image.

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": {
      "file": "<file>"
    },
    "name": "export_image"
  }
}

Input Schema

Name	Required	Description
`file`	Yes	Where to write the PNG (folders are made)
`path`	No	Or a path from images.res, e.g. "0203070200/GenericCarAdjuster/AmbianceLight/Interior_LHD.png"
`index`	No	The image index in images.mcf
`which`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 7, 2026

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose that this writes to the local filesystem and that it can pull either the stored image or the unsaved replacement, but it is silent on overwrite behavior when the target file already exists, on permissions, and on what (if anything) is returned.

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

Conciseness5/5

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

A single sentence with the verb and resource front-loaded and zero filler; every clause (local computer, stored vs unsaved, round-trip with replace_image) carries information. The colon construction is slightly informal but does not impede parsing.

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 simple export tool with no output schema, the description covers what it writes, where relative to the agent, which image version it picks up, and the follow-up step. The only meaningful gap is the absence of any note on return value or existing-file handling.

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 description coverage is 75%, and the description still adds meaning: the parenthetical 'as stored, or its unsaved replacement' explains the current/new semantics of the 'which' enum, which the schema leaves undocumented. It does not clarify how 'file' and 'path' relate or how index selection interacts with them, but the core added value is there.

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?

The description gives a specific verb and resource ('Writes one image of the skin to a PNG file') and immediately scopes it to the local computer and the stored-or-unsaved state. It also names the sibling it is the inverse of ('bring it back with replace_image'), so an agent can separate it from replace_image and replace_images without reading either schema.

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

Usage Guidelines4/5

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

It states a concrete use case ('to edit it in another tool') and names the follow-up tool to use afterwards, which effectively routes the agent between export and replace_image. It does not state exclusions or what to do when no file write is wanted, so it stops short of fully explicit when/when-not guidance.

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