LPC Character Generator — MCP

by kyuza1

Overview Schema Source Related Servers Discussions Admin

Python

Local

generate_character

Build an LPC character spritesheet as a PNG and export it for Godot, Unity, or web, with split animations and credits.

Instructions

Builds the character spritesheet and saves it as PNG.

Every result has animation_check: whether every item has every animation and, if not, what is missing plus complete alternatives. TELL the user when complete=false. prefer_complete=True swaps incomplete items for the closest item with every animation (keeping the color when possible) and lists the swaps in replaced. Only use it with the user's consent: it changes the look (e.g. apron becomes overalls). output_dir: folder to save into (e.g. the game project's sprites folder). Inside a Godot project the .tres gets the right res:// path; for Unity, save inside Assets/. Default: LPC_OUTPUT_DIR or ~/lpc-characters.

items: list of {"id": "", "color": "" | ["<color 1>", "<color 2>"], "variant": ""}. Include a body (body/body) and a head (e.g. head/heads/human/heads_human_male). Skin items (head, ears, nose...) without a color inherit the body color. Multi-part items (see color_parts in get_item) accept a list of colors. body_type: male | female | muscular | pregnant | teen | child animations: subset of walk, idle, slash, thrust, spellcast, shoot, hurt, run, jump... (default: all). Oversized weapon/tool animations (e.g. slash_128, tool_hammer) are added automatically when their base animation (slash, thrust...) is requested. layout: "standard" = same layout as the site (832px wide, each animation always on the same row; oversized animations below y=3456). It is what Godot/Unity/RPG Maker importers expect. "compact" = only the requested animations, stacked. split: also save pieces. True or "animation" = one PNG per animation (_anims/); "frame" = one PNG per frame (_frames//_NN.png); "item" = one sheet per item (_items/), for swapping outfits in-game. Can be a list: ["animation", "frame"]. export: engine-ready files: "godot" (SpriteFrames .tres), "unity" (sliced sprites .meta, .anim clips and an AnimatorController), "web" (JSON atlas for Phaser/PixiJS + demo page), "site" (JSON for the generator site's "Import from Clipboard" button). licenses: license families you accept (e.g. ["CC0", "OGA-BY"] for Steam). Items outside them are listed in warnings. Every result has license_check (drm_safe, share_alike_required) computed from the art actually used. zip: also pack everything generated for this character into .zip. Always writes _credits.txt and _credits.csv with authors and licenses of the art used, including a ready-to-paste credits-screen statement (credits.statement).

Input Schema

TableJSON Schema

Name	Required	Default
`zip`	No
`items`	Yes
`split`	No
`export`	No
`layout`	No	standard
`filename`	No	character.png
`licenses`	No
`body_type`	No	male
`animations`	No
`output_dir`	No
`prefer_complete`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.0Oct 1, 2026

addedInput schema / properties / licenses

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Licenses"
+}

addedInput schema / properties / zip

Added value: +{
+  "default": false,
+  "title": "Zip",
+  "type": "boolean"
+}

First observedv0.1.0Sep 28, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so richly: it discloses animation_check, license_check, warnings, replaced swaps, the consent requirement for prefer_complete, automatic oversized animation inclusion, and the credits files always written. This gives the agent a clear picture of side effects, outputs, and safety considerations.

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?

The description is long but front-loaded with the core purpose, then proceeds through parameter explanations efficiently. Each sentence adds useful detail, though the dense parameter-by-parameter format could be more visually structured. Length is justified by the tool's complexity and the absence of schema descriptions.

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

Completeness5/5

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

For a complex 11-parameter generation tool with no annotations and no output schema, the description is remarkably complete. It explains behavior, output artifacts, validation checks, warnings, and parameter semantics well enough that an agent can invoke it correctly without additional context.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must explain all 11 parameters, and it does so for nearly every one: items structure, body_type values, animations subset, layout modes, split modes, export targets, licenses filtering, zip packaging, output_dir defaults, and prefer_complete behavior. Only filename is not explicitly described, which is a minor omission given the overall compensation.

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 opens with a specific verb and resource: 'Builds the character spritesheet and saves it as PNG.' This clearly separates it from preview-only or batch tools by specifying that it writes a PNG artifact. An agent can understand the core operation without opening the schema.

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 description gives extensive guidance for individual parameters, including when to use prefer_complete only with user consent and when to use standard vs. compact layout. However, it never explicitly compares this tool to siblings like preview_character, random_character, or generate_batch, so tool-selection guidance is only implied.

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

Deploy Server

generate_character

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools