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

@ola/buzz-mcp

Official
by ola-krutrim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

buzz_archive_channel

DestructiveIdempotent

Archive or unarchive a Buzz channel to set read-only access; archiving requires owner/admin rights and confirmation, and dry-run previews changes.

Instructions

Archive (read-only for everyone) or unarchive a channel (kind 9002 archived tag; owner/admin only). Archiving needs confirm: true. archived defaults to true; pass false to unarchive.

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

Input Schema

NameRequiredDescriptionDefault
channelYeschannel name or id
confirmNoset true to confirm a destructive action (asked once per session per kind in wire / post-as-me mode)
dry_runNopreview only: resolve everything and show the exact event that would be signed (auth tags redacted) — nothing is signed, uploaded or sent
archivedNotrue = archive (default), false = unarchive

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.36

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the permission gate (owner/admin only), the consequence for other users (channel becomes read-only for everyone), and the confirm requirement for the archiving direction only. It does not say whether unarchiving also requires confirmation, which leaves a small gap.

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?

A single compact sentence-pair with the primary action and effect front-loaded, then the confirm and default-value details. Every clause carries information; there is no filler or restatement of the title.

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 4-parameter, non-read-only tool with no output schema, the description covers permission requirements, the user-visible effect, the confirm gate, and the default direction. Only minor items are absent — whether unarchive also needs confirm and what happens to existing content — so it is close to complete.

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?

Schema description coverage is 100%, so channel, confirm, dry_run and archived are all already documented in the schema, and the description largely restates the `archived` and `confirm` semantics. It adds only marginal value — clarifying that confirm applies to archiving specifically — which is the expected baseline 3 when the schema does the heavy lifting.

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 states a specific verb pair (archive/unarchive) and resource (channel), plus the concrete effect ('read-only for everyone') and the underlying mechanism (kind 9002 archived tag). It implicitly separates this from destructive siblings like buzz_delete_channel by emphasizing read-only rather than removal, though it never names a sibling explicitly.

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?

It gives clear operational guidance — 'Archiving needs confirm: true' and '`archived` defaults to true; pass false to unarchive' — but this is parameter-level instructions rather than tool-selection guidance. An agent is not told when to choose archive vs. leave_channel vs. delete_channel, nor what prerequisites (e.g., role) must hold before calling.

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