Skip to main content
Glama
kyuza1
by kyuza1

generate_character

Create and export LPC character spritesheets as PNGs from chosen items and animations, ready for Godot, Unity, or web projects.

Instructions

Gera a spritesheet do personagem e salva em PNG.

Todo resultado traz animation_check: se todos os itens têm todas as animações e, se não, quais faltam e alternativas completas. AVISE o usuário quando complete=false. prefer_complete=True troca sozinho itens incompletos pelo parecido mais próximo que tem todas as animações (mantendo a cor quando dá) e lista as trocas em replaced. Só use com o aval do usuário: a troca muda o visual (ex.: avental vira macacão). output_dir: pasta onde salvar (ex.: a pasta de sprites do projeto do jogo). Se ficar dentro de um projeto Godot, o .tres já sai com o caminho res:// certo; num projeto Unity, salve dentro de Assets/. Padrão: LPC_OUTPUT_DIR ou ~/lpc-characters.

items: lista de {"id": "", "color": "" | ["<cor 1>", "<cor 2>"], "variant": ""}. Inclua um corpo (body/body) e uma cabeça (ex.: head/heads/human/heads_human_male). Itens de pele (cabeça, orelhas, nariz...) sem cor herdam a cor do corpo. Itens com várias partes (ver color_parts em get_item) aceitam uma lista de cores. body_type: male | female | muscular | pregnant | teen | child animations: subconjunto de walk, idle, slash, thrust, spellcast, shoot, hurt, run, jump... (padrão: todas). Animações especiais de armas/ferramentas (ex.: slash_128, tool_hammer) entram automaticamente quando a animação base delas (slash, thrust...) é pedida. layout: "standard" = mesmo layout do site (832px de largura, cada animação sempre na mesma posição; animações especiais vêm abaixo, a partir de y=3456). É o formato que importadores de Godot/Unity/RPG Maker esperam. "compact" = só as animações pedidas, empilhadas. split: também salva em partes. True ou "animation" = um PNG por animação (_anims/); "frame" = um PNG por quadro (_frames/<animação>/<direção>_NN.png); "item" = uma folha por item (_items/), para trocar roupas no jogo. Pode ser uma lista: ["animation", "frame"]. export: arquivos prontos para engines: "godot" (SpriteFrames .tres), "unity" (.meta com os sprites fatiados + clipes .anim), "web" (atlas JSON para Phaser/PixiJS + página de demonstração), "site" (JSON para o botão "Import from Clipboard" do site). Sempre salva _credits.txt e _credits.csv com autores e licenças das artes usadas.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYes
splitNo
exportNo
layoutNostandard
filenameNocharacter.png
body_typeNomale
animationsNo
output_dirNo
prefer_completeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/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 the animation_check return concept, the replaced list, the visual side effect of substitution ('avental vira macacão'), always-emitted credits files, and per-engine export artifacts. It omits timeout/cost behavior and whether existing files are overwritten, but the side-effect profile is unusually rich.

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 purpose and then organized per parameter, and the length is justified by 9 undocumented parameters. Sentences are dense with usable detail rather than filler, though a few parenthetical examples (Godot/Unity paths) could be tightened.

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 complex 9-parameter tool with no annotations and no output schema, the description supplies the output contract (PNG spritesheet, credits files, split/export artifacts) and the animation_check semantics an agent needs to report back. Only the filename parameter and overwrite behavior are unaddressed.

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 0%, so the description must compensate, and it documents items structure with color/inheritance rules, body_type, animations, layout, split variants, export targets, and output_dir defaults. Only filename is left undocumented, which is a small gap against otherwise thorough compensation.

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?

The opening sentence states a specific verb and resource (generate the character's spritesheet and save it as PNG), which is concrete and actionable. It distinguishes the tool's saving behavior from preview-style siblings implicitly, but never names preview_character or generate_batch, so an agent gets no explicit differentiation.

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 guidance is present but embedded in parameter talk: prefer_complete is gated on user consent, and the agent is told to warn the user when complete=false. There is no statement of when to choose this tool over preview_character or generate_batch, so the when-vs-alternative question 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.