Skip to main content
Glama
@ola/buzz-mcp

@ola/buzz-mcp

Official
by ola-krutrim

buzz_remind

Set encrypted self-reminders with flexible timing plus an optional note or channel message, synced across Buzz desktop and mobile; the relay only sees when they fire.

Instructions

Set a reminder for yourself (like Slack's /remind) — NIP-ER kind 30300, NIP-44 encrypted to you so the relay only sees when it fires, synced with the Buzz desktop and mobile apps. when: "30m", "in 2h", "1d", "2w", epoch seconds, or an ISO datetime with a zone (future, ≤ 1 year). Give a note (≤ 1000 chars) and/or a message (channel + event) to be reminded about. Agent mode only (needs encrypt-to-self).

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

Input Schema

NameRequiredDescriptionDefault
noteNowhat to remind you of (≤ 1000 chars)
whenYes30m / in 2h / 1d / 2w / epoch seconds / ISO datetime with zone
eventNoremind about this message <id> (needs `channel`)
channelNochannel name or id
dry_runNopreview only: resolve everything and show the exact event that would be signed (auth tags redacted) — nothing is signed, uploaded or sent

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.36

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: NIP-ER kind 30300, NIP-44 encryption to self so 'the relay only sees when it fires', cross-device sync with desktop/mobile, and the agent-mode encryption prerequisite. These are real operational facts (privacy model, delivery mechanism, runtime requirement) that no annotation conveys.

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 purpose, then constraints, then the precondition — a sensible order with no filler sentences. It is dense and protocol jargon (NIP-ER, NIP-44) plus the app-sync aside add length without helping invocation decisions.

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

Completeness5/5

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

For a single-purpose mutation tool with no output schema, the description covers what it does, the accepted time formats, the one-year bound, the two reminder payload shapes, and the auth/agent-mode requirement. Return values need not be described given the tool's simplicity.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: `when` must be in the future and within one year, and `note` and the `channel`/`event` pair are an 'and/or' choice rather than independent inputs. The `dry_run` parameter is left entirely to the schema, which is the only gap.

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 ('Set a reminder for yourself') and anchors it with a familiar analogue ('like Slack's /remind'), which immediately separates it from buzz_reminders (listing) and buzz_reminder_done. The self-scoped target ('for yourself') further narrows it against any team-wide notification concept.

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

Usage Guidelines4/5

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

Explains the two usage patterns clearly: give a `note` and/or a message via `channel` + `event`. It also states a hard precondition ('Agent mode only (needs encrypt-to-self)') that an agent must check before calling. It stops short of naming alternatives or stating when not to use it.

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