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

@ola/buzz-mcp

Official
by ola-krutrim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

buzz_workflow_run

Trigger a workflow you own in a Buzz channel with optional named inputs, or use dry_run to preview the exact event before signing. Refused for unowned or disabled workflows.

Instructions

Manually trigger a workflow YOU own in a channel (kind 46020). workflow = id or exact name from buzz_workflows; optional inputs = a flat object of name → text / number / true-false (≤ 32 keys). Refused for a workflow you don't own or that is disabled. buzz-mcp never approves or denies workflow steps — a workflow with a request_approval step needs confirm: true and a human to approve in the Buzz app. Agent mode only for now (kind 46020 isn't on the wire-sign allowlist).

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

Input Schema

NameRequiredDescriptionDefault
inputsNotrigger inputs: name → text / number / boolean
channelYeschannel name or id
confirmNorequired when the workflow has a request_approval step (it will wait for a human)
dry_runNopreview only: resolve everything and show the exact event that would be signed (auth tags redacted) — nothing is signed, uploaded or sent
workflowYesthe workflow id or exact name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.36

TDQS

A4.5/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), the description discloses refusal conditions (not owned / disabled), that the tool never approves or denies steps itself, and that an approval step will block pending a human in the app. What it does not cover is the success-side behavior — whether a run id is returned, whether the call blocks, or whether repeated triggers are safe.

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 the action, then constraints in decreasing priority; nearly every clause carries information. Minor redundancy from repeating 'kind 46020' twice and the slightly opaque 'wire-sign allowlist' phrasing.

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 nested-input, mutation-style trigger tool with no output schema and no annotations explaining workflow semantics, the definition covers preconditions, approval flow, and failure modes well. The remaining gap is what a successful invocation yields or how long it may block for approval, which an agent would want to know before calling.

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 baseline is 3, but the description adds meaning: workflow accepts an id or exact name sourced from buzz_workflows, inputs must be a flat name→scalar object under the key cap, and confirm is tied to the presence of a request_approval step and to human approval rather than a mere boolean flag. Only dry_run is 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 ('Manually trigger a workflow YOU own in a channel') plus the workflow kind identifier. It is easy to distinguish from the sibling buzz_workflows, which is for listing/browsing rather than execution.

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

Usage Guidelines5/5

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

Explicitly sets the when-to-use context (manual trigger), the ownership and enabled/disabled preconditions, the pointer to buzz_workflows as the source of valid workflow ids/names, and the special case requiring confirm:true plus human approval. It even names the environment restriction ('agent mode only for now').

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