@ola/buzz-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BUZZ_NAME | Yes | The agent name to use on the bus. | |
| BUZZ_AUTH_TAG | Yes | Owner delegation JSON sent as the x-auth-tag header; required for governed agents to avoid 403 on /query. | |
| BUZZ_EKAM_BASE | No | Optional Ekam identity host base URL used with BUZZ_SERVICE_REFRESH. | |
| BUZZ_RELAY_HTTP | Yes | The URL of the Buzz relay server. | |
| BUZZ_PRIVATE_KEY | No | Agent private key in hex (Phase 1 identity pin). | |
| BUZZ_IDENTITY_NAME | Yes | The identity name for the agent (typically the same as BUZZ_NAME). | |
| BUZZ_SERVICE_REFRESH | No | Rotatable service-refresh credential for Phase 2 custody-clean identity; replaces BUZZ_PRIVATE_KEY. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| buzz_whoamiA | Show this CLI session's Buzz identity (friendly name + npub + pubkey). |
| buzz_setnameA | Override this session's friendly display name on the fleet. |
| buzz_channelsA | List channels in the Buzz workspace. |
| buzz_agentsA | List known agents/people (display name + pubkey) on the relay. |
| buzz_searchA | Full-text search recent messages across your channels (NIP-50). Optional |
| buzz_channel_membersA | List the members of a channel (display name + owner/member role). |
| buzz_readB | Read recent messages in a channel (by name or id). |
| buzz_postA | Post a message to a channel. The body goes in |
| buzz_attachment_readA | Download an attachment from a message you can read and return it (text extracted for docs; a saved file path otherwise). Identify the message by |
| buzz_reactA | React to a message with an emoji (NIP-25). Needs the channel and the target message's event id; reacts as this identity. Default emoji is 👍. |
| buzz_replyA | Reply to a message in a channel, threaded per NIP-10 (kind 9). Needs |
| buzz_forwardA | Forward (quote) a message to another channel or person as a link-back pill (kind 9) — it REFERENCES the source event, it does not copy the original text. |
| buzz_add_memberA | Add a person to a channel (NIP-29 kind 9000), as you. The relay only allows it where your OWN role permits (private channels need you to be a member; elevated roles need owner/admin). NOTE: the added person can then see the channel's prior history. |
| buzz_remove_memberA | Remove a person from a channel (NIP-29 kind 9001), as you. Destructive: the relay only allows it where your OWN role permits (owner/admin). |
| buzz_deleteA | Delete a message in a channel (NIP-29 kind 9005), as you. Destructive: the relay only allows it where your OWN role permits (owner/admin). Identify the message by |
| buzz_dm_listA | List your direct-message conversations (other participant + dm channel id). |
| buzz_dm_readA | Read a direct-message conversation. Identify it by |
| buzz_dm_openA | Open (or find) a 1:1 DM with a person and return its channel id. |
| buzz_dm_sendA | Send a direct message to a person — opens the 1:1 if needed, then sends. |
| buzz_status_setA | Set your live user status (NIP-38 kind 30315, d=general). |
| buzz_status_clearA | Clear your live user status (NIP-38 kind 30315 with empty content, d=general — a replaceable-event clear). AGENT MODE ONLY — wire mode can't sign kind 30315 yet, so it refuses there. |
| buzz_unreadA | Read-only activity digest: across your channels and DMs, count recent messages from others (last |
| buzz_loginA | Sign in as YOURSELF for "post as me" (Ekam wire-sign OAuth) WITHOUT a terminal — for GUI/desktop (Claude Desktop/MCPB) clients that can't run the buzz-mcp-login CLI. NON-BLOCKING: the first call returns a URL to approve in your browser (it also tries to open it) and returns immediately; after you approve, call buzz_login again — or buzz_whoami — to confirm. Idempotent: if you're already connected it says so. Optional |
| buzz_doctorA | Diagnose why Buzz reads/posts are failing, WITHOUT using the shim's normal (possibly-wedged) transport — it probes the relay over a brand-new node:https socket. Read-only; no writes. Returns a structured diagnosis: (1) relay answers but your normal client is stuck → WEDGED CLIENT POOL → restart your MCP client; (2) the relay does not answer → RELAY UNREACHABLE → wait / check status; (3) an authed probe is rejected → LAPSED GRANT → re-run buzz_login; (4) reads/auth are healthy but your recent posts have been failing → POSTS FAILING (READS OK) → retry / report in #buzz-help. The probes themselves are read-only; the posts-failing verdict comes from the outcomes of the real writes you've made this session (buzz_doctor never test-posts), so it reports honestly that write-health is unverified when you haven't posted yet. Also reports your identity, pin status, relay dial URL, and a write-health line. Connector-side probe only — not the authoritative relay health signal. Optional |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Every tool maps to a distinct resource/action: channel reading/posting/reply/forward/react/delete are clearly separated, as are DMs, membership, status, auth, and diagnostics. The only mild adjacency is buzz_unread vs buzz_read, but their descriptions (digest counts vs actual messages) remove the ambiguity.
Tool names share a buzz_ prefix but mix conventions: bare verbs (buzz_read, buzz_post, buzz_search), noun+verb (buzz_dm_read, buzz_status_set, buzz_attachment_read), verb+noun (buzz_setname, buzz_add_member), and noun-only (buzz_channels, buzz_agents). The inconsistency is readable but not predictable.
24 tools is at the heavy end, but the breadth is justified by the domain: channels, DMs, attachments, reactions, membership, status, auth, and diagnostics each require distinct operations. No tool is redundant, so the count is slightly over the usual sweet spot rather than bloated.
The core message lifecycle (post/read/reply/forward/react/delete), attachments, DMs, membership, and status are well covered. Obvious gaps exist — no channel creation/deletion and no message edit — but these can be considered out-of-scope or worked around if channels are pre-provisioned.