Skip to main content
Glama

export_godot_spriteframes

Read-onlyIdempotent

Make a Godot 4 SpriteFrames resource (.tres) and the sheet PNG it references, the same files as the Godot Exporter on voidless.dev/tools: one AtlasTexture per frame, named animations with fps and loop. Give frames (packed into a grid sheet) or a sheet (kept as is, grid auto-detected unless given). Each animation picks frames by index (frames or first/last) or brings its own images; with no animations every frame plays as "default". Save the PNG as .png in the folder the .tres names. For a Voidless character give asset_id: alone it exports every clip of the asset (named as in get_asset); or give each animation's frame_id (from get_asset; -1 = the base image, image_index picks one rotation view), or just a name matching one of its frames, or frames/images that are its image keys. Their images, sprite_scale and feet come from the asset, and the export puts every animation at ONE pixel scale with the feet on ONE point (video clips are drawn ~0.57x the base, so mixing them with rotations or the base otherwise changes the size). It returns the world height, px per world unit and the node scale/offset to use (_scale.json, also in the .tres metadata): set the AnimatedSprite2D's scale to node_scale (unit_px / px_per_unit) and offset as given, the same unit_px for every character, instead of guessing sizes. Images up to 2048x2048, 256 frames, 32 MB of input per call. Free: no credits.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "export_godot_spriteframes"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoBase file name: <name>.png and <name>_frames.tressheet
sheetNoInstead of frames: one sprite sheet image, cut into frames row by row.
folderNoGodot folder the PNG will live in, e.g. res://sprites/hero/res://
framesNoFrames in order, each an image (https URL, library image key, data: URI or base64). An animated GIF counts as all its frames.
columnsNoSheet columns when frames are packed (default 8; a roughly square sheet for over 64 frames)
unit_pxNoScreen px of one world unit in the game (the hero's height): the node scale is computed for it
asset_idNoA Voidless image asset. Alone: every clip of it, evened out to one scale. With animations: those with frame_id (or a name matching one of its frames) take their images, scale and feet from it; frames that are its image keys take their scale from it
even_outNoWith scale data: resample each animation to one px per unit and one feet point (default). false keeps the frames and returns a GDScript helper that sets scale/offset per animation
max_sheetNoLargest sheet side in px for an asset export (4096 loads on every phone GPU); the frames are shrunk to fit
animationsNo
sheet_rowsNoRows of the sheet (with sheet).
px_per_unitNopx per world unit in the base image (default: asset_id's)
supersampleNoWith display_height: frame px per screen px (2 keeps HD art crisp when drawn smaller)
world_heightNoWorld height in units (default: asset_id's)
sheet_columnsNoColumns of the sheet (with sheet). Omit columns and rows to auto-detect the grid.
display_heightNoWith asset_id: how many screen px tall the character is drawn in the game. The frames are made supersample x that (instead of the art's full size), so a whole character fits one small sheet and one reply. Omit to keep the art's size (within max_sheet)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / display_height
      Added value: +{
      +  "description": "With asset_id: how many screen px tall the character is drawn in the game. The frames are made supersample x that (instead of the art's full size), so a whole character fits one small sheet and one reply. Omit to keep the art's size (within max_sheet)",
      +  "maximum": 2048,
      +  "minimum": 8,
      +  "type": "integer"
      +}
    • addedInput schema / properties / max_sheet
      Added value: +{
      +  "default": 4096,
      +  "description": "Largest sheet side in px for an asset export (4096 loads on every phone GPU); the frames are shrunk to fit",
      +  "maximum": 16384,
      +  "minimum": 512,
      +  "type": "integer"
      +}
    • addedInput schema / properties / supersample
      Added value: +{
      +  "default": 2,
      +  "description": "With display_height: frame px per screen px (2 keeps HD art crisp when drawn smaller)",
      +  "maximum": 4,
      +  "minimum": 1,
      +  "type": "number"
      +}
  2. First observed

TDQS

A3.7/5.0
Behavior1/5

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

The description adds valuable limits and return details (2048x2048, 256 frames, 32 MB, world height, px per unit, node scale/offset). However, it says the tool makes a resource and saves a PNG into a folder, which is a write side effect, while annotations declare readOnlyHint=true. That direct conflict with the safety annotation forces the lowest score.

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 purpose and key modes are front-loaded, and most content is relevant for this 16-parameter tool. But the description is a dense, semicolon-heavy paragraph that is harder to scan than necessary.

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 export tool with no output schema, it covers file outputs, naming/folder behavior, input limits, returned scale metadata, and asset-specific workflows. The remaining parameter details are handled by the high-coverage schema.

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 coverage is 94%, so most parameter meaning is already documented. The description still adds useful cross-parameter semantics for asset_id, frame_id/image_index, even-out scaling, and node scale/offset, though it leaves packing details such as columns, sheet_rows, sheet_columns, and supersample to the schema.

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 uses a specific verb and resource: it makes a Godot 4 SpriteFrames .tres plus the sheet PNG, with AtlasTexture frames and named animations. It clearly identifies the outputs and the two main input modes, so an agent can distinguish it from generic sheet-packing or animation tools.

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 explains the principal calling modes: frames versus a prebuilt sheet, asset_id alone versus per-animation frame_id/name/frames/images, and the default behavior when no animations are supplied. It does not explicitly compare against sibling tools such as pack_sprite_sheet, so it falls short of full 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources