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

@ola/buzz-mcp

Official
by ola-krutrim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

buzz_create_channel

Create a new Buzz channel and become its owner, choosing private (invite-only) or open visibility and stream or forum type. Add members afterward with buzz_add_member.

Instructions

Create a new channel (NIP-29 kind 9007), as you — you become its owner. name is required. visibility: "private" (invite-only; the DEFAULT — fail-closed) or "open" (searchable, anyone self-joins). type: "stream" (default) or "forum". Optional description, and ttl (seconds — an ephemeral channel archived after that much idle). Does NOT add members: after creating, add them with buzz_add_member. The relay authorizes this against your own channel-write permission; it may refuse if your identity/delegation lacks it. name is at most 80 characters and description at most 500, neither containing control characters.

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

Input Schema

NameRequiredDescriptionDefault
ttlNooptional idle-seconds before the channel is archived (ephemeral)
nameYeschannel name (a leading # and surrounding whitespace are trimmed; ≤80 chars, no control characters)
typeNo"stream" (default) or "forum"
dry_runNopreview only: resolve everything and show the exact event that would be signed (auth tags redacted) — nothing is signed, uploaded or sent
visibilityNo"private" (default) or "open"
descriptionNooptional channel description/about (≤500 chars)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.36

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so safety is covered. The description adds genuinely new behavior: relay-side authorization against the caller's own channel-write permission, possible refusal due to identity/delegation limits, and ttl-driven ephemeral archival. It doesn't say what happens on name collision or what the relay returns on success.

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?

Front-loaded with the action, then defaults, then the membership exclusion, then authorization and validation limits — a logical order with no filler sentences. It is dense to the point of being a single run-on block with many backticked fragments, which slightly hurts scanability.

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?

With no output schema, the description covers the important operational facts an agent needs (ownership transfer, auth refusal, member-adding gap, length limits). It stops short of indicating what a successful create returns or how the new channel is referenced afterward.

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 semantic weight beyond the terse schema text: it spells out the consequences of visibility ("private" = invite-only and default; "open" = searchable, anyone self-joins) and explains ttl as idle-driven archival rather than a bare number. It leaves dry_run to the schema, which already describes it well.

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+resource ("Create a new channel") plus the protocol marker (NIP-29 kind 9007) and the resulting ownership state ("you become its owner"). An agent can distinguish it from buzz_channels, buzz_edit_channel, and buzz_join_channel 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?

Explicitly bounds scope with a when-not: "Does NOT add members: after creating, add them with buzz_add_member" names the alternative tool and the follow-up step. Defaults are stated as fail-closed (private visibility, stream type), which tells the agent what happens if it omits options.

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