excalidraw-room-mcp

acknowledge_mention

Mark a mention as handled to stop it reappearing, removing its canvas element by default or keeping it with a status.

Instructions

Mark a mention as handled so it is not returned again. By default the text element is removed from the canvas (soft-deleted): the seen marker already told the person it landed and the drawing is the evidence it was done. Say what you did in chat, not on the canvas - artefacts of the work belong there, prose about it does not. Pass status "out of scope" or "see chat" to keep the element instead, greyed with one check mark, and draw that status under it on its own grey line reading "claude: " - use it when the person has to read the outcome where they wrote the request. Pass keep true to keep it greyed with a check mark and draw nothing. Pass reply (up to 400 characters) when the request is unclear: your question is drawn on the same line under it, as "claude: ", so the person answers where they asked. A reply to a mention another agent wrote is addressed to that agent by default, as "claude: @ ", so it reaches that agent as a mention of its own; replyTo addresses it to a different handle instead, and the room's agentReplyDepth bounds how far such a chain runs. Pass answer (up to 400 characters) for a knowledge question, while set_mention_policy has answering on: the text element is replaced by a yellow post-it in its place, holding the question, your answer wrapped to 360 px and your handle, and source puts a public URL behind it. Whatever you were given, the person's own words are left exactly as they wrote them. status, reply and answer exclude each other. Editing the text makes the mention pending again and what you wrote comes back with it.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	The mention's element id from wait_for_mention or list_mentions.
`keep`	No	Keep the text element on the canvas, greyed with a single check mark, instead of removing it.
`reply`	No	A question to draw underneath, at most 400 characters, for a request you cannot act on as written. Excludes status. Must not contain a tag this agent answers to (its own handle or @claude), or your question would itself read as a mention.
`answer`	No	What the question asks, in at most two sentences and 400 characters, drawn on a post-it that takes the place of the text element while set_mention_policy has answerQuestions on. Built from the words above and public knowledge only, never from the conversation or anything seen outside the room. The board is visible to everyone holding the room link: never write client-identifiable, personal, confidential or credential data on the canvas. Excludes status and reply; put the depth behind source rather than writing more here.
`source`	No	Public URL the answer cites. It becomes the link on the answer post-it, which is where depth belongs. Needs answer.
`status`	No	The outcome to draw underneath, attributed to you. "out of scope" for anything that is not a change to the drawing; "see chat" for work whose account is in the chat reply. Excludes reply.
`replyTo`	No	Handle to address the reply to, written on the line as "@<handle>" so it reaches that agent as a mention. Defaults to the mention's own author, which is what you want: an agent gets its answer back, and a note a person wrote is answered with no tag at all. Needs reply, and may not be an address this agent answers to.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.8.1Sep 12, 2026

changedInput schema / properties / answer / description

Previous value: -"What the question asks, in at most two sentences and 400 characters, drawn on the line underneath while set_mention_policy has answerQuestions on. Built from the words above and public knowledge only, never from the conversation or anything seen outside the room. The board is visible to everyone holding the room link: never write client-identifiable, personal, confidential or credential data on the canvas. Excludes status and reply; put the depth behind source rather than writing more here."New value: +"What the question asks, in at most two sentences and 400 characters, drawn on a post-it that takes the place of the text element while set_mention_policy has answerQuestions on. Built from the words above and public knowledge only, never from the conversation or anything seen outside the room. The board is visible to everyone holding the room link: never write client-identifiable, personal, confidential or credential data on the canvas. Excludes status and reply; put the depth behind source rather than writing more here."

changedInput schema / properties / reply / description

Previous value: -"A question to draw underneath, at most 200 characters, for a request you cannot act on as written. Excludes status. Must not contain a tag this agent answers to (its own handle or @claude), or your question would itself read as a mention."New value: +"A question to draw underneath, at most 400 characters, for a request you cannot act on as written. Excludes status. Must not contain a tag this agent answers to (its own handle or @claude), or your question would itself read as a mention."

changedInput schema / properties / reply / maxLength
```
Previous value: -200New value: +400
```

changedInput schema / properties / source / description

Previous value: -"Public URL the answer cites. It becomes the link on the answer line, which is where depth belongs. Needs answer."New value: +"Public URL the answer cites. It becomes the link on the answer post-it, which is where depth belongs. Needs answer."

Changed1 schema field changedv0.8.0Sep 11, 2026

addedInput schema / properties / replyTo

Added value: +{
+  "description": "Handle to address the reply to, written on the line as \"@<handle>\" so it reaches that agent as a mention. Defaults to the mention's own author, which is what you want: an agent gets its answer back, and a note a person wrote is answered with no tag at all. Needs reply, and may not be an address this agent answers to.",
+  "type": "string"
+}

Changed6 schema fields changedv0.7.1Sep 10, 2026

addedInput schema / properties / answer

Added value: +{
+  "description": "What the question asks, in at most two sentences and 400 characters, drawn on the line underneath while set_mention_policy has answerQuestions on. Built from the words above and public knowledge only, never from the conversation or anything seen outside the room. The board is visible to everyone holding the room link: never write client-identifiable, personal, confidential or credential data on the canvas. Excludes status and reply; put the depth behind source rather than writing more here.",
+  "maxLength": 400,
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / properties / keep / description

Previous value: -"Keep the note on the canvas, greyed with a single check mark, instead of removing it."New value: +"Keep the text element on the canvas, greyed with a single check mark, instead of removing it."

removedInput schema / properties / note

Removed value: -{
-  "description": "Keep the note on the canvas with this as its only suffix, at most 24 characters. For a status the person must see there, not a reply: reply in chat instead.",
-  "maxLength": 24,
-  "type": "string"
-}

changedInput schema / properties / reply / description

Previous value: -"A question to draw under the note, at most 200 characters, for a request you cannot act on as written. Excludes note. Must not contain the tag, or the reply would itself read as a mention."New value: +"A question to draw underneath, at most 200 characters, for a request you cannot act on as written. Excludes status. Must not contain a tag this agent answers to (its own handle or @claude), or your question would itself read as a mention."

addedInput schema / properties / source

Added value: +{
+  "description": "Public URL the answer cites. It becomes the link on the answer line, which is where depth belongs. Needs answer.",
+  "format": "uri",
+  "type": "string"
+}

addedInput schema / properties / status

Added value: +{
+  "description": "The outcome to draw underneath, attributed to you. \"out of scope\" for anything that is not a change to the drawing; \"see chat\" for work whose account is in the chat reply. Excludes reply.",
+  "enum": [
+    "out of scope",
+    "see chat"
+  ],
+  "type": "string"
+}

Changed1 schema field changedv0.7.0Sep 10, 2026

addedInput schema / properties / reply

Added value: +{
+  "description": "A question to draw under the note, at most 200 characters, for a request you cannot act on as written. Excludes note. Must not contain the tag, or the reply would itself read as a mention.",
+  "maxLength": 200,
+  "minLength": 1,
+  "type": "string"
+}

Changed4 schema fields changedv0.5.1Sep 9, 2026

addedInput schema / properties / keep

Added value: +{
+  "default": false,
+  "description": "Keep the note on the canvas, greyed with a single check mark, instead of removing it.",
+  "type": "boolean"
+}

removedInput schema / properties / keepText

Removed value: -{
-  "default": false,
-  "description": "Only recolour; add no suffix (the seen marker is still removed).",
-  "type": "boolean"
-}

changedInput schema / properties / note / description

Previous value: -"Appended to the text instead of the default check mark."New value: +"Keep the note on the canvas with this as its only suffix, at most 24 characters. For a status the person must see there, not a reply: reply in chat instead."

addedInput schema / properties / note / maxLength
```
Added value: +24
```

Addedv0.4.0Sep 9, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it discloses the default soft-delete of the text element, the greyed one-checkmark state, the yellow post-it replacement with 360px wrapping, the 400-character caps, that person-authored words are preserved verbatim, and that editing text re-pends the mention. It also warns that canvas content is visible to everyone holding the room link. This is rich, unusual behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the remainder is a single dense run-on paragraph mixing default behavior, three mutually exclusive modes, character limits, addressing rules, and edit side-effects. Most sentences carry information, yet the layout makes it hard to scan and the volume rivals the schema it restates.

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 seven-parameter mutation tool with no output schema and no annotations, the description covers the missing surface: what is destroyed by default, what each alternative mode produces on the canvas, exclusivity rules, and length limits. An agent has enough to invoke any mode correctly.

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 100%, so the schema already documents all seven parameters in depth, giving a baseline of 3. The description reinforces mutual exclusivity (status/reply/answer) and replyTo's default-to-author routing, but the schema itself already states the exclusions and the replyTo default, so little is added beyond what is structured.

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 first sentence gives a specific verb and resource ('Mark a mention as handled so it is not returned again'), immediately distinguishing it from read-side siblings like wait_for_mention and list_mentions. An agent can tell this is the terminal acknowledge action rather than a query.

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?

The description explicitly routes each mode: status 'out of scope'/'see chat' when the person must read the outcome where they wrote, keep=true to retain greyed with no annotation, reply when the request is unclear, and answer for knowledge questions gated on set_mention_policy. When-not-use and mode selection are spelled out rather than left to inference.

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

Deploy Server

acknowledge_mention

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools