Skip to main content
Glama
jdsalasca

Aseprite Asset MCP

by jdsalasca

generate_environment_pack

Create complete environment asset packs for beach, forest, village, or cave scenes. Specify dimensions, seed, and output prefix to generate deterministic Aseprite plans and Godot manifests.

Instructions

Generate a complete beach, forest, village, or cave asset pack.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYes
seedYes
widthYes
heightYes
tile_sizeNo
detail_levelNohigh
output_prefixYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that a 'complete' asset pack is generated, but does not disclose what the output looks like, whether side effects occur, how the seed affects results, or what 'complete' means in practice.

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

Conciseness3/5

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

The single sentence is lean and free of filler, earning its place as a basic summary. However, for a tool with seven parameters and no annotation support, this level of brevity crosses from conciseness into under-specification.

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?

Given the tool's complexity (7 parameters, no output schema, no annotations), the description is incomplete. It lacks information about return values, parameter behavior and constraints, and how this tool relates to the many sibling generation tools, leaving an agent under-informed for correct invocation.

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

Parameters1/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, but it only restates the 'kind' enum values already present in the schema. It adds no meaning for the required parameters output_prefix, width, height, seed, or the optional tile_size and detail_level.

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 description names a specific verb ('Generate'), a resource ('asset pack'), and enumerates the supported environment kinds ('beach, forest, village, or cave'). This makes the tool's scope clear and helps distinguish it from non-environment generation tools, though it does not explicitly differentiate it from close siblings like generate_beach_scene or generate_terrain_tileset.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. With many sibling generation tools such as generate_asset_preset, generate_beach_scene, and export_asset_pack, the description gives no selection criteria, exclusions, or prerequisite context.

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