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

@ola/buzz-mcp

Official
by ola-krutrim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

buzz_status_clear

DestructiveIdempotent

Clears your live Buzz user status by publishing an empty NIP-38 replaceable event, removing your current status from the relay. Agent mode only; supports a dry run to preview the event before signing.

Instructions

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "buzz_status_clear"
  }
}

Input Schema

NameRequiredDescriptionDefault
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. Changed2 schema fields changedv0.2.36
    • addedInput schema / additionalProperties
      Added value: +false
    • 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"
+}
  2. Addedv0.2.7

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructive=true, idempotent=true and openWorld=true, so the safety profile is covered. The description adds genuinely new behavioral context: the signer-mode gating that makes the tool refuse in wire mode, plus the replaceable-event/empty-content semantics of what actually happens to the status. It doesn't cover auth requirements or the return shape.

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?

Two sentences: purpose front-loaded, then protocol detail in a parenthetical, then the mode gate. The parenthetical is jargon-dense ('NIP-38 kind 30315 with empty content, d=general') but earns its place for a protocol-level tool 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 single-parameter, no-output-schema tool, the description covers purpose, protocol semantics and the key failure mode (wire mode refusal). The remaining gap is minor: no indication of what a successful clear returns or whether it errors when no status is set (the idempotent annotation hints it is safe).

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?

There is one optional parameter and schema description coverage is 100%, so the dry_run preview semantics are fully documented in the schema itself. The description adds nothing about parameters; baseline 3 applies when the schema does all the work.

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?

The description opens with a specific verb and resource ('Clear your live user status') and pins down the exact protocol effect (NIP-38 kind 30315, empty content, d=general, replaceable event), which implicitly separates it from buzz_status_set. It stops short of naming the sibling explicitly, so the contrast relies on inference.

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?

It gives a strong situational constraint — 'AGENT MODE ONLY — wire mode can't sign kind 30315 yet, so it refuses there' — telling the agent exactly when this call will fail. It doesn't route to a fallback or explicitly contrast with buzz_status_set for setting a status, but for a clear operation there is no real alternative.

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