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

@ola/buzz-mcp

Official
by ola-krutrim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

buzz_thread_read

Read-onlyIdempotent

Reads a complete NIP-10 discussion thread from any root or reply message, returning the root plus all replies for full context.

Instructions

Read a whole thread: the root message plus every reply (NIP-10). event may be the root or any reply in it.

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

Input Schema

NameRequiredDescriptionDefault
eventYesthe target message's <id> (from buzz_read)
limitNomax replies (default 50, max 200)
channelYeschannel name or id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.36

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld, so safety is covered. The description adds genuine semantics beyond them: the result is the entire thread resolved via NIP-10, and the entry point can be any reply rather than only the root. It omits ordering and how the limit truncates the reply set, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the core behavior front-loaded, then the parameter nuance. No filler, no repetition of the title or annotations.

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 three-parameter read tool with no output schema, the description covers what is returned (root plus all replies) and the flexible entry point. Missing only lower-value details such as reply ordering and whether `limit` truncates newest or oldest replies.

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, and the description earns above that by clarifying that `event` is not restricted to the root message but may be any reply — a behavior the schema's 'the target message's <id>' wording leaves ambiguous. `channel` and `limit` are left entirely to the schema.

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 and resource ('Read a whole thread') plus precise scope ('the root message plus every reply (NIP-10)'). This clearly separates it from buzz_read (single message), buzz_reply (write), and buzz_dm_read without needing the schema.

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?

The clause '`event` may be the root or any reply in it' tells an agent it can enter the thread from any node, which is real usage guidance. However, it never explicitly contrasts with the sibling buzz_read or states when a full-thread read is preferable to a single-message read, so selection between them stays implied.

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