Skip to main content
Glama
kyuza1

LPC Character Generator — MCP

by kyuza1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

generate_batch

Generate multiple random LPC character spritesheets at once for towns or crowds, saving each as numbered PNG files with credits.

Instructions

Generates many random characters at once (e.g. villagers for a town). Saves _01.png, _02.png... and the credits for each. body_types: bodies to pick from (default: male and female). fixed_items: items everyone gets (e.g. [{"id": "tools/tool_hammer"}]).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seedNo
countNo
splitNo
exportNo
layoutNostandard
prefixNonpc
licensesNo
animationsNo
body_typesNo
output_dirNo
fixed_itemsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.0
    • addedInput schema / properties / licenses
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Licenses"
+}
  2. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the file side effect and naming convention (<prefix>_01.png, <prefix>_02.png...) plus that credits are saved. However it omits permissions, whether existing files are overwritten, rate/scale limits, and the default output location implied by output_dir.

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?

Front-loaded with the core purpose in the first sentence, followed by output behavior and the two documented parameters. The inline JSON example for fixed_items is compact, though it edges toward schema duplication rather than description value.

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

Completeness2/5

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

A batch-mutation tool with 11 parameters, no annotations, and no output schema leaves too much unexplained: nine parameters undocumented, no auth/permission notes, no overwrite behavior, and no locality of output described beyond the filename pattern.

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

Parameters2/5

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

Schema coverage is 0% across 11 parameters, yet the description documents only body_types and fixed_items (with an example). The other nine (seed, count, split, export, layout, prefix, licenses, animations, output_dir) get no meaning at all, so agents cannot reason about most inputs.

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 (generates many random characters at once) with a concrete framing example ('villagers for a town'), clearly distinguishing a batch operation from the single-character siblings. It stops short of explicitly naming the alternative tools like generate_character, so it is clear but not sibling-differentiated.

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 'many at once' framing implies batch use, and the villagers example hints at the scenario, but it never says when to prefer this over generate_character or how it relates to random_character. 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.

Deploy Server

Other Tools