Skip to main content
Glama

scene_remove_entities

Destructive

Removes entities from a copy of a scene save by exact names or a name prefix, so unwanted placed objects can be deleted without rebuilding the level from the base map.

Instructions

Take things that were placed in the scene out of a copy of a save: a floor piece that was laid in the wrong place, a row of fences that turned out not to be needed, the pieces of a version of the scene that is being replaced. names is a list of entity names (each exactly, as scene_list_entities gives them; every entity of that name goes), or namePrefix takes all whose names begin with it (at least two characters). Importing a scene can only add; this is how to take away without starting over from the base map. The entities every map has by itself (the stage entity, the player slots) are refused. A graph that looks a removed thing up by its GUID finds nothing afterwards. Returns a new .gil; the official save is not touched, so go on from the copy. Seen in the game on 2026-10-13: a level with three of its wall pieces removed opened in the editor and played, the walls gone and the rest as before.

Input Schema

NameRequiredDescriptionDefault
namesNo
mapPathNo
namePrefixNo
outputNameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already flag destructive/non-readonly, and the description adds meaningful context beyond them: the official save is untouched, a new .gil is produced, base-map entities are refused, and graphs resolving a removed GUID afterwards find nothing. The in-game verification note further vouches for the destructive operation's actual effects.

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?

Long but front-loaded: purpose, examples, parameter behavior, mutation semantics, then the verification anecdote. The closing playtest note is somewhat expendable, but the rest of the prose earns its place.

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

Completeness4/5

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

No output schema exists, and the description does state the return ('a new .gil') plus the safety model (official save untouched). The main gap is the unexplained mapPath/outputName inputs on a 4-parameter destructive tool, which leaves an agent guessing about where input comes from and where output lands.

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

Parameters3/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 carry parameter meaning. It explains names well (exact names as scene_list_entities reports, all entities of that name removed) and namePrefix (minimum two characters, prefix match), but mapPath and outputName are never named or explained, leaving half the parameters undocumented.

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?

States a specific verb and resource (remove previously placed entities from a copy of a save) and gives concrete examples (floor piece, fences, replaced scene pieces). It also explicitly separates itself from the add-direction siblings and from importing a scene, so an agent can tell what it does without opening the schema.

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?

Gives clear context for when to reach for it: 'Importing a scene can only add; this is how to take away without starting over from the base map.' It also states a hard exclusion (stage entity and player slots are refused). It does not address overlap between names and namePrefix or multi-scene workflows, but the primary usage framing is clear.

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