Skip to main content
Glama

Tileset Manage

tileset_manage

Create TileSet atlas sources and inspect them by listing occupied tile positions or retrieving the atlas texture as a PNG for visual verification.

Instructions

TileSet management — atlas inspection tools.

Ops: • tileset_create_atlas(resource_path, texture_path, tile_size, tiles, source_id=0, margins=None, separation=None, overwrite=False) Build a saved TileSet with one native atlas source. tile_size is {x,y} in pixels and sets both TileSet tile size and atlas cell size. tiles is [{"coords":{"x":0,"y":0},"size":{"x":1,"y":1}}]; size defaults to one cell. margins/separation are {x,y} pixel offsets, default zero. At most 4096 nonoverlapping tiles, all within the texture. No terrain, collision, animation or alternative-tile configuration is performed. Persistent, not scene-undoable. overwrite replaces the whole TileSet while retaining UID. Use existing atlas read ops to inspect the result.

• tileset_get_atlas_tiles(tileset_path, source_id) Return all occupied atlas tile positions for one source in a TileSet. Read-only — does not modify any resource or project file.

    tileset_path: res:// path to the .tres TileSet resource (required)
    source_id:    raw TileSet source id of the TileSetAtlasSource to query (required, ≥ 0)

    Returns:
      {"tiles": [{"col": int, "row": int}, ...], "count": int}

    Error codes (passed through from GDScript handler):
      MISSING_REQUIRED_PARAM  — tileset_path empty or source_id absent
      RESOURCE_NOT_FOUND      — tileset_path does not exist on disk
      WRONG_TYPE              — not a TileSet, or source is not a TileSetAtlasSource
      VALUE_OUT_OF_RANGE      — source_id does not exist in this TileSet

• tileset_get_atlas_image(tileset_path, source_id, max_size=0) Return the atlas sprite-sheet texture of a TileSetAtlasSource as a Base64-encoded PNG image. Read-only — reads the texture directly from the resource without any UI interaction.

    tileset_path: res:// path to the .tres TileSet resource (required)
    source_id:    raw TileSet source id of the TileSetAtlasSource to query (required, ≥ 0)
    max_size:     optional int; if > 0, scale the image so its longest
                  edge is at most max_size pixels (default 0 = full res)

    Returns:
      {"image_base64": str, "width": int, "height": int,
       "original_width": int, "original_height": int, "format": "png"}

    Error codes (passed through from GDScript handler):
      MISSING_REQUIRED_PARAM  — tileset_path empty or source_id absent
      RESOURCE_NOT_FOUND      — tileset_path does not exist on disk
      WRONG_TYPE              — not a TileSet, source not a TileSetAtlasSource,
                                or source has no texture assigned
      VALUE_OUT_OF_RANGE      — source_id does not exist in this TileSet

• Atlas image workflow: To visually inspect what tiles look like, use tileset_get_atlas_image instead of editor screenshots. It reads the texture directly from the resource — no UI interaction or editor state required.

Canonical call shape: {"op": "<verb>", "params": {...}}. Flat op parameters are accepted as a compatibility alias when the client transmits them; op and session_id remain top-level.

Input Schema

NameRequiredDescriptionDefault
opYes
paramsNo
session_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.4.1
    • changedInput schema / properties / op / enum
      Previous value: -[
      -  "tileset_get_atlas_image",
      -  "tileset_get_atlas_tiles"
      -]New value: +[
      +  "tileset_create_atlas",
      +  "tileset_get_atlas_image",
      +  "tileset_get_atlas_tiles"
      +]
  2. Addedv3.1.4
  3. Removedv3.0.7
  4. First observedv2.9.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: it declares the two read ops as read-only and non-mutating, and discloses that create is "Persistent, not scene-undoable" and that overwrite "replaces the whole TileSet while retaining UID." It further enumerates hard constraints (max 4096 nonoverlapping tiles, all within the texture) and lists the exact error codes each op can return.

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?

Structure is strong: one bulleted block per op with signature, prose, and return/error sections, plus the canonical call shape at the end. It is on the long side and repeats itself — tileset_path and source_id are documented in both the op signature and a separate parameter list, and read-only is asserted twice for get_atlas_image — but almost every line carries information an agent needs.

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 three-op dispatcher with a bare op/params/session_id schema and no annotations, the description supplies everything needed: per-op parameters with defaults, return value shapes, error code semantics, mutation guarantees, and the envelope format including the flat-parameter compatibility alias. Nothing material is missing for correct invocation.

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 supply all parameter meaning, and it does: tile_size is {x,y} in pixels and sets both TileSet tile size and atlas cell size, tiles is a list of coords/size with size defaulting to one cell, margins/separation are {x,y} pixel offsets defaulting to zero, and max_size scales the longest edge when > 0. Required flags and constraints (source_id ≥ 0, res:// path) are stated inline.

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 scoped purpose ("TileSet management — atlas inspection tools") and then enumerates three named operations with specific verbs and resources: create a saved TileSet with a native atlas source, return occupied tile positions, return the atlas texture as Base64 PNG. Each op is distinguishable from the sibling families tilemap_manage and gridmap_manage because the scope is explicitly TileSet atlas resources.

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 gives real routing advice inside the tool: "Use existing atlas read ops to inspect the result" after a create, and a dedicated "Atlas image workflow" section directing agents to tileset_get_atlas_image instead of editor screenshots. It also scopes what create does not do (no terrain, collision, animation, or alternative tiles). The one gap is that it never states when to pick this tool over the tilemap_manage sibling.

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