Excalidraw · Holon

sync

For the board's page: send the Excalidraw elements it changed and where its pointer is. With since, also receive the elements changed elsewhere and everyone else's cursors.

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": {
      "board": "<board>",
      "client": "<client>",
      "elements": "<elements>"
    },
    "name": "sync"
  }
}

Input Schema

Name	Required	Description
`board`	Yes	The board's id, as in its URL.
`since`	No
`client`	Yes	Names the calling page, so that it is not told its own changes.
`elements`	Yes
`presence`	No

Output Schema

Name	Required	Description
`seq`	Yes	Pass as since next time.
`epoch`	Yes	Changes when the server has lost its boards: send every element again.
`cursors`	Yes
`elements`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond the sole destructiveHint=false annotation, the description discloses the core exchange behavior: local changed elements and pointer are sent, and with since remote elements and other cursors are also returned. It still omits merge/conflict semantics and permission expectations, but it gives substantial behavioral context for a sync endpoint.

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

Conciseness5/5

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

Two tightly written sentences front-load the target board and then distinguish the base send behavior from the since-dependent receive behavior. There is no filler or repetition.

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?

For a five-parameter nested sync tool, the description covers the core send/receive model, the optional since branch, and presence; the output schema covers return values and the input schema documents board and client. Remaining gaps are mainly merge/conflict semantics and explicit client behavior, which are not fully addressed in the description.

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?

The prose gives functional meaning to board, elements, presence, and since, notably that since triggers receipt of remote changes and cursors. The client parameter is only explained in the schema, and nested element version fields remain schema-only, but the description compensates well for much of the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the board page and states the exchange: changed Excalidraw elements plus pointer presence, with since enabling receipt of remote changes and cursors. It is clearly a sync operation rather than draw/erase/read, but it does not explicitly name or differentiate those siblings.

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

Usage Guidelines3/5

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

It implies when to call it, namely to send local changes and presence, and explains the conditional effect of since for receiving remote changes. However, it gives no explicit when-not guidance or alternatives such as read_board or draw, leaving selection to inference.

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

All Excalidraw · Holon tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.