Skip to main content
Glama

Create or update a GM sticky note

dos2_put_note
DestructiveIdempotent

Creates or updates a Game Master-only sticky note on an Overview map, finding existing notes by key or title and backing up the note file before writing.

Instructions

Creates a Game Master sticky note on an Overview map, or changes an existing note. Players never see these notes. An existing note is found by key if given, otherwise by an equal title; if none matches, a new one is created on the map.

A note inside a scene hangs on an invisible marker item of the level, so new scene notes have to be placed in
the game; for one that already exists this tool changes title, text and folder and keeps its binding.

Writes Notes.lsf. The previous file is backed up first; undo with dos2_restore. Fails with an error while the game process is running unless allow_running=true.
Fails with an error if the map is not found or has to be specified. Returns created, the note's uuid, where it
sits and the backup id. Read notes with dos2_notes; remove one with dos2_delete_note.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "campaign": "<campaign>",
      "title": "<title>",
      "text": "<text>"
    },
    "name": "dos2_put_note"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNoHorizontal position on the map in map pixels. Default 600 for a new note.
yNoVertical position on the map in map pixels. Default 400 for a new note.
keyNoStable identifier of your choice. The note's UUID is derived from it, so the same key always addresses the same note even after its title changes.
mapNoOverview map to put the note on: the map's title or UUID from dos2_campaign. May be omitted when the campaign has exactly one map or the note already exists.
textYesNote text. Line breaks are kept.
titleYesNote title. Without key, an existing note with the same title is updated.
folderNoFolder the note is filed under in the notes overview. Omit to keep the current one.
campaignYesThe campaign to work on: its name, its folder name, its UUID, or a unique part of any of them. dos2_status lists the campaigns.
allow_runningNoKeep false. Set true only after the user has confirmed that the running game sits in the main menu: a write into a campaign that is loaded in the game gets lost or damages it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.1.1
    • addedInput schema / properties / allow_running / description
      Added value: +"Keep false. Set true only after the user has confirmed that the running game sits in the main menu: a write into a campaign that is loaded in the game gets lost or damages it."
    • addedInput schema / properties / campaign / description
      Added value: +"The campaign to work on: its name, its folder name, its UUID, or a unique part of any of them. dos2_status lists the campaigns."
    • addedInput schema / properties / folder / description
      Added value: +"Folder the note is filed under in the notes overview. Omit to keep the current one."
    • addedInput schema / properties / key / description
      Added value: +"Stable identifier of your choice. The note's UUID is derived from it, so the same key always addresses the same note even after its title changes."
    • addedInput schema / properties / map / description
      Added value: +"Overview map to put the note on: the map's title or UUID from dos2_campaign. May be omitted when the campaign has exactly one map or the note already exists."
    • addedInput schema / properties / text / description
      Added value: +"Note text. Line breaks are kept."
    • addedInput schema / properties / title / description
      Added value: +"Note title. Without key, an existing note with the same title is updated."
    • addedInput schema / properties / x / description
      Added value: +"Horizontal position on the map in map pixels. Default 600 for a new note."
    • addedInput schema / properties / y / description
      Added value: +"Vertical position on the map in map pixels. Default 400 for a new note."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already flag destructiveHint and idempotentHint, but the description adds what is actually touched (Notes.lsf), that the previous file is backed up first, how to undo, the failure mode when the game process is running, the failure case for a missing map, and the return payload. That is substantial behavior beyond the structured hints.

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 core resolution rule is front-loaded in the first paragraph and the third paragraph packs side effects, failure modes and return values tightly. It is a little dense at three paragraphs, but nearly every sentence carries operational information.

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 9-parameter destructive write tool with no output schema, the description covers the write target, backup/undo path, runtime preconditions, failure cases and the shape of the return value. Nothing an agent needs in order to invoke it safely is missing.

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 coverage is 100%, so the baseline is 3; the description still adds real meaning by explaining the key-versus-title resolution rule and the failure when the map is absent or ambiguous, which is orchestration logic the schema cannot express. It leaves the x/y and folder defaults to the schema, which is fine but stops short of a 5.

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 names a specific verb and resource and immediately states the create-or-update duality plus the lookup rule (key first, then equal title, else create). That is enough to distinguish it from dos2_notes, dos2_delete_note and dos2_restore without opening any schema.

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 explicit when-to-use and when-not-to-use guidance: read with dos2_notes, delete with dos2_delete_note, undo with dos2_restore, and do not run while the game is loaded unless allow_running=true. The scene-note restriction (new scene notes must be placed in the game) is stated as a hard condition.

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