Skip to main content
Glama

scene_add_graph

Destructive

Add an empty node graph to a copied save, attach server graphs to entities or prefabs, and return its graphId as targetGraphId for write_graphs.

Instructions

Add an empty node graph to a copy of a save and, for a server graph, attach it. The platform is event driven and its games are many small graphs, each on the entity it is about: attachToPrefab puts the graph on a prefab (元件) so that every copy of it, placed or created later, runs its own instance and receives its own events (a coin that is picked up, a pay station, a door); attachToPrefab "player" puts it on the player template (per-player state such as score) and "character" on the character template; attachTo names one placed entity (default 关卡实体, the stage entity: level-wide things such as the clock, and the only place that hears whenEntityIsDestroyed of objects and creatures). An entity can run several graphs, and one graph can sit on several prefabs that behave alike (attachToPrefab as a list: a wooden and a stone wall, three kinds of coin). kind makes another kind of graph instead, none of which is attached to an entity: boolFilter, a client graph with a yes/no test that an option of an option tab can name so that it shows only to players for whom it is true (scene_add_components filterGraphId; verified in play); characterSkill, the client graph a skill runs (scene_add_skill names it; verified in play); item, a server graph that hears the events of one item, such as its being used from the backpack (scene_add_item useGraphId names it; verified in play); creatureSkill, creatureStatus, creatureDecision, the client graphs of complex creatures: what a skill of the creature does, one of its behaviours (a list of tactics and skills), and the graph that picks the behaviour (scene_add_creature_skill and scene_set_creature_logic wire them to a creature; verified in play, read_knowledge {id:"example-brain"}). A new map has no node graph, and write_graphs needs one to write into: call this, then use the returned graphId as targetGraphId. The name gets the prefix GSTS if it lacks it (graphs with that prefix are the ones these tools may overwrite). Writes a new .gil in the workspace and returns its path; the official save is not touched.

Input Schema

NameRequiredDescriptionDefault
kindNoserver
nameNo
mapPathNo
attachToNo
outputNameNo
attachToPrefabNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that it writes a new .gil in the workspace, that the official save is not touched, that names receive the _GSTS_ prefix, and that graphs with that prefix are the ones these tools may overwrite. This adds concrete operational context not captured by destructiveHint/readOnlyHint alone.

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 and dense, but that length is largely justified by the complexity of seven graph kinds and multiple attachment modes. It front-loads the core action and usage condition, though some sentences are run-on and could be more clearly structured.

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?

Given the complex behavior, zero schema descriptions, and no output schema, the description is substantially complete: it explains the workflow, attachment semantics, file-writing behavior, and returned graphId/path. The remaining gap is that mapPath and outputName are not explicitly described.

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 description coverage is 0%, so the description must carry parameter meaning. It explains kind at length for all seven enum values, and explains attachToPrefab, attachTo, and the name-prefix behavior, but it does not directly explain mapPath or outputName, leaving a gap for two of the six parameters.

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 states a specific verb and resource: add an empty node graph to a copy of a save, and attach it when it is a server graph. It explicitly distinguishes this tool from write_graphs by explaining that write_graphs needs a graph created here first.

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

Usage Guidelines5/5

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

It gives an explicit when-to-use condition: a new map has no node graph and write_graphs needs one, so call this then use the returned graphId as targetGraphId. It also explains the attachment alternatives and the non-attached kind options with their downstream wiring tools.

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