An agent can write door_Look() perfectly well; what it could not do was attach that function to the door inside a compiled room file. Every write tool takes an outputFile, so the safe pattern is built into the parameters instead of left to your discipline — and the batch tools exist because hotspot edits come in sets, not singles.
An editor for Adventure Game Studio compiled room files (.crm). AI tools already write AGS script text; this reads and writes the binary room data that connects those functions to hotspots, so the hookup step no longer has to happen by hand in the editor.
- read_room_data parses a .crm file into structured room data; list_room_blocks lists the blocks inside it
- export_room_block writes a block out to a file and import_room_block replaces one from a file
- get_room_hotspots extracts hotspot information; list_hotspot_interactions lists what is attached to one hotspot
- add_hotspot_interaction attaches an event handler function to a hotspot event; remove_hotspot_interaction takes one off
- modify_hotspot_properties changes name, script name and walk-to coordinates; update_hotspot_walkto_coordinates does it across several hotspots at once; batch_modify_hotspots applies multiple operations in a single call
- Hotspot handlers follow the AGS naming convention hotspot{id}_{event}, so a generated function like hotspot1_Look resolves at runtime
Node.js 18 or newer; run it with npx ags-mcp-server over stdio. Windows, macOS and Linux. No credentials. It needs .crm files on paths it can read, and the editing tools take an outputFile rather than writing over the original in place. Reads and writes are pure Node with no external AGS binaries. Hotspots and blocks are what it edits today — room objects, walkable areas, regions and character spawn points are on the roadmap, not in the tool list.
One command — npx ags-mcp-server