Godot AI

by hi-godot

Overview Schema Source Related Servers Discussions Admin

Local

Tilemap Manage

tilemap_manage

Set, fill, clear, and read TileMapLayer cells in Godot scenes by path, with undoable edits for level authoring.

Instructions

TileMap / TileMapLayer authoring (set tiles, fill rects, clear, read cells).

All operations target TileMapLayer nodes in the currently edited scene by scene-relative path (e.g. "/LavaLake20x20/Ground"). All write ops are undoable via EditorUndoRedoManager.

source_id is the TileSet source index. atlas_col/atlas_row are the atlas coordinates of the tile within that source. For full-tile animated sources (lava, water, sewage) use atlas_col=0, atlas_row=0.

IMPORTANT — Source-ID remapping in specialized .tres files: When a layer uses a specialized .tres (e.g. volcano_animated.tres), Source-IDs are re-numbered from 0. Example: volcano lava is Source 8 in the main volcano.tres but Source 0 in volcano_animated.tres. Always use the remapped ID when the TileMapLayer references a specialized .tres, not the original ID from the main .tres.

Ops: • tilemap_set_cell(path, source_id, atlas_col, atlas_row, map_x, map_y) Set a single tile at (map_x, map_y). Returns: {map_x, map_y, source_id, atlas_col, atlas_row}

• tilemap_set_cells_rect(path, source_id, atlas_col, atlas_row, rect_x, rect_y, rect_w, rect_h) Fill a rect_w × rect_h region starting at (rect_x, rect_y) with one tile type in a single undo action. Returns: {cells_filled, rect: {x, y, w, h}}

• tilemap_clear(path) Remove all tiles from the layer. Returns: {cleared: true}

• tilemap_get_cells(path) Return all used cell coordinates. Returns: {cells: [{x, y}, ...], count: int}

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

TableJSON Schema

Name	Required	Description	Default
`op`	Yes
`params`	No
`session_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.9.1Jul 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses that all write operations are undoable, that operations target scene-relative TileMapLayer paths, and that specialized .tres files renumber source IDs. It does not cover error conditions or permission requirements, but for an editor authoring tool this is substantial transparency.

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 well organized: a brief overview, a critical source-ID remapping warning, and a flat list of operations with signatures and returns. The length is justified by the tool's complexity, though some redundancy exists between the overview and the op list.

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 multi-op tool with no annotations and no schema-level parameter documentation, this description is complete. It covers target paths, coordinate systems, source-ID remapping pitfalls, undo behavior, return shapes, and the required call envelope. An agent has enough to select and invoke any of the four operations correctly.

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 compensate, and it does thoroughly. It documents each op's parameter list, explains source_id, atlas_col/atlas_row semantics, gives specialized .tres remapping examples, and describes return values. It also clarifies the canonical call shape versus the flat compatibility alias.

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 specific verb and resource: 'TileMap / TileMapLayer authoring (set tiles, fill rects, clear, read cells).' This clearly distinguishes the tool from sibling tools like tileset_manage or gridmap_manage by naming the exact target resource and operation families.

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 description provides strong usage context: all operations target TileMapLayer nodes in the currently edited scene by scene-relative pathjans, and it explains when source-id remapping matters. However, it does not explicitly state when to prefer this tool over sibling tools or when not to use it, leaving some selection judgment to the agent.

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