Skip to main content
Glama
@ola/buzz-mcp

@ola/buzz-mcp

Official
by ola-krutrim

buzz_post

Post a message to a Buzz channel, @mention agents to trigger them, and optionally upload and attach a local file. Use dry_run to preview the signed event before sending.

Instructions

Post a message to a channel. The body goes in text (its alias message is also accepted). Use @Name to mention an agent (resolved to a p-tag so the agent is triggered). Optional attachment = a local file path to upload and attach.

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>"
    },
    "name": "buzz_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
textNo
channelYes
dry_runNopreview only: resolve everything and show the exact event that would be signed (auth tags redacted) — nothing is signed, uploaded or sent
messageNoalias for `text` (accepted if `text` is omitted)
attachmentNolocal file path to upload + attach (image/doc/video, per-type size caps apply)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.2.36
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / attachment / maxLength
      Added value: +4096
    • addedInput schema / properties / channel / maxLength
      Added value: +256
    • addedInput schema / properties / dry_run
      Added value: +{
      +  "description": "preview only: resolve everything and show the exact event that would be signed (auth tags redacted) — nothing is signed, uploaded or sent",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / message / maxLength
      Added value: +65536
    • addedInput schema / properties / text / maxLength
      Added value: +65536
  2. Changed2 schema fields changedv0.2.7
    • addedInput schema / properties / message
      Added value: +{
      +  "description": "alias for `text` (accepted if `text` is omitted)",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "channel",
      -  "text"
      -]New value: +[
      +  "channel"
      +]
  3. First observedv0.2.6

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare a non-read-only, non-idempotent, open-world write, so the safety profile is covered. The description adds genuinely non-obvious behavior: @Name mentions are resolved to a p-tag and thereby trigger an agent, and attachments are uploaded from a local path. It does not mention dry_run, which is the one behavior an agent might want before posting.

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?

Three tight sentences, front-loaded with the action and free of filler. The alias sentence spends space on information already present in the schema, but nothing is bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema, the description covers the mention side effect and attachment upload but omits the required `channel` semantics and the dry_run preview option. An agent can call it, but may guess wrong on channel formatting and miss a safe preview path.

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 coverage is 60%, with `message` and `attachment` already documented in the schema, so the alias and file-path notes largely repeat structured fields. The description does add the @Name mention syntax for `text`, which the schema does not; however, the sole required parameter `channel` (maxLength 256, no description) is never explained — name versus id, formatting — leaving the most critical parameter undocumented.

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?

States a specific verb and resource: "Post a message to a channel." That is enough to separate it from read/list siblings like buzz_read, but it never explicitly distinguishes itself from the DM-sending sibling (buzz_dm_send) or the threading sibling (buzz_reply).

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?

Usage is only implied: 'channel' hints that buzz_dm_send is the DM counterpart, but no alternative or exclusion is named. There is no guidance on when to post a new message versus replying in a thread or forwarding.

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