Skip to main content
Glama
Sign In
@ola/buzz-mcp

@ola/buzz-mcp

Official
by ola-krutrim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

buzz_canvas_write

Destructive

Replace a channel's shared canvas with new markdown, using a head check against a prior read to refuse writes when the canvas changed, so concurrent edits aren't silently overwritten.

Instructions

Replace a channel's canvas with new markdown (kind 40100) — it overwrites the WHOLE canvas for everyone. Read it first with buzz_canvas_read and pass the head id it showed as expected_head ("none" if there was no canvas): the write is refused if the canvas changed since your read (re-read, merge, retry). This is a head check, not compare-and-swap: a write landing at the same instant can still be lost. content ≤ 128 KB; empty content only with clear: true. Agent mode only for now (kind 40100 isn't on the wire-sign allowlist).

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": {
      "channel": "<channel>",
      "content": "<content>",
      "expected_head": "<expected_head>"
    },
    "name": "buzz_canvas_write"
  }
}

Input Schema

NameRequiredDescriptionDefault
clearNoset true (with empty content) to blank the canvas
channelYeschannel name or id
contentYesthe full new canvas markdown (≤ 128 KB)
dry_runNopreview only: resolve everything and show the exact event that would be signed (auth tags redacted) — nothing is signed, uploaded or sent
expected_headYesthe head id from buzz_canvas_read (full 64-hex), or "none" if the channel had no canvas

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.36

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds much more: it discloses blast radius (whole canvas, affects everyone), the optimistic-concurrency protocol, the honest caveat that it is a head check rather than true compare-and-swap so same-instant writes can be lost, the 128 KB limit, and the kind 40100 wire-sign allowlist restriction.

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?

The destructive scope and the required read-first step are front-loaded, then caveats, then limits. Every clause carries operational information — even the compare-and-swap caveat prevents a real failure mode — and there is no filler.

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 destructive mutation with no output schema, the description covers prerequisites, failure modes, size limits, and mode restrictions thoroughly. The one gap is what happens on success (e.g. whether the new head id is returned for a subsequent chained write), which matters since there is no output schema to fall back on.

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 schema already documents all five parameters; the baseline would be 3. The description still adds real semantics beyond the schema: the sentinel value "none" for expected_head, the required read-before-write relationship between expected_head and buzz_canvas_read, and the coupling of empty content to clear: true.

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?

States a specific verb and resource ('Replace a channel's canvas with new markdown (kind 40100)') plus the key scope fact that it overwrites the whole canvas for everyone. This clearly distinguishes it from the sibling buzz_canvas_read, which it names explicitly.

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?

Gives an explicit prerequisite workflow: read first with buzz_canvas_read, pass the head id as expected_head, use "none" when there was no canvas, and on refusal 're-read, merge, retry'. It also states a conditional constraint (empty content only with clear: true) and an availability restriction (agent mode only).

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