Tools reference
Every buzzabout__* MCP tool — the assistant flow (ask / get_message / render) plus read-only lookups.
The MCP server exposes 15 tools. They fall into two kinds:
- The assistant flow —
ask→get_message→render. This is where the work happens.askhands a prompt to the buzzabout assistant, which writes the search query, previews it, collects posts, profiles audiences, detects patterns, and analyses — then returns the answer as text or an interactive widget. - Read-only lookups — list and fetch the datasets, runs, mentions, audience profiles, and tracking agents the account already has.
There are no create / update / delete tools. Anything that makes
or runs something — collecting a dataset, profiling an audience,
detecting patterns — happens through buzzabout__ask. The read tools
only surface what already exists. (Programmatic CRUD lives on the
REST API.)
All tools require auth — see Authentication. Both
x-api-key and OAuth/JWT callers can use every tool, including ask.
The assistant flow: ask → get_message → render
ask is asynchronous — research can run for minutes, past a host's
tool-call timeout — so it returns immediately with an id, and you poll
get_message for the answer.
buzzabout__ask
Hand a prompt to the assistant. Returns right away; does not wait for the answer.
| Field | Type | Required | Notes |
|---|---|---|---|
prompt | string | yes | Free-form question or instruction. |
chat_id | string | no | Continue a prior chat. Omit to start fresh. |
dataset_ids | string[] | no | Scope the assistant to specific datasets. A fresh chat has none linked — pass these when the question is about a known dataset. |
post_refs | { id, source }[] | no | Pin specific posts as context (cap 50). |
{
"chat_id": "01H...",
"message_id": "01H...",
"status": "working"
}Keep the chat_id to continue the conversation; pass chat_id +
message_id to get_message to retrieve the answer.
buzzabout__get_message
Poll for the answer to an ask. Long-polls — one call holds for up
to ~45s, returning the moment the turn settles, so you call it
back-to-back rather than waiting between calls.
| Field | Type | Required |
|---|---|---|
chat_id | string | yes |
message_id | string | yes |
{
"chat_id": "01H...",
"message_id": "01H...",
"status": "working", // or "completed" / "failed"
"stop_reason": null, // non-null once finished
"blocks": [
{ "block_id": "b1", "type": "text", "render": false, "text": "...markdown..." },
{ "block_id": "b2", "type": "openui", "render": true }
]
}blocks arrive only once the turn settles. Walk them in order: a
render: true block is an interactive widget — call render; a
render: false block already carries its text — relay it to the user
as-is.
If a run is genuinely long and you're low on tool calls, stop polling
and tell the user — the chat is saved, and you (or they, next turn) can
resume with the same chat_id + message_id.
buzzabout__render
Render one render: true block as an interactive MCP App widget
(hosts that support the io.modelcontextprotocol/ui extension). Bound
to the ui://buzzabout/message UI resource.
| Field | Type | Required |
|---|---|---|
message_id | string | yes |
block_id | string | yes |
Returns the block's OpenUI as structuredContent the host renders
natively. Only call it on render: true blocks — a render: false
block has no widget to draw.
Hosts without the MCP Apps extension can't draw widgets. For them
the assistant returns the answer as plain markdown (relayed via
get_message), so no render call is needed.
Read-only lookups
These look up entities the account already owns — they never create or
charge. All list_* tools are cursor-paginated (see below).
Datasets
| Tool | Required parameters | Returns |
|---|---|---|
buzzabout__list_datasets | — | { content: Dataset[], cursor } |
buzzabout__get_dataset | dataset_id | Dataset or { error } |
buzzabout__get_dataset_run | dataset_id, run_id | DatasetRun (status envelope) |
Audience
| Tool | Required parameters | Returns |
|---|---|---|
buzzabout__list_audience_datasets | — | { content: AudienceDataset[], cursor } |
buzzabout__get_audience_dataset | audience_dataset_id | AudienceDataset |
buzzabout__get_audience_dataset_run | audience_dataset_id, run_id | AudienceDatasetRun (status envelope) |
buzzabout__list_audience_profiles | — | { content: Profile[], cursor } |
list_audience_profiles defaults to all account-owned audience
datasets. Mirrors POST /v1/audience_profiles.
Mentions
| Tool | Required parameters | Returns |
|---|---|---|
buzzabout__list_mentions | — | { content: Mention[], cursor } |
Defaults to all account-owned datasets; pass dataset_ids to narrow.
Filters, sort, order, cursor, limit mirror the
REST mentions endpoint.
Patterns
| Tool | Required parameters | Returns |
|---|---|---|
buzzabout__get_pattern_detection_run | run_id | { run_id, status, pattern_id } (polling shape) |
Pattern detection is started through ask; this read polls a run's
status. The pattern's content flows back through the assistant.
Tracking agents
| Tool | Required parameters | Returns |
|---|---|---|
buzzabout__list_tracking_agents | — | { content: TrackingAgent[], cursor } |
buzzabout__get_tracking_agent | agent_id | TrackingAgent |
Account
| Tool | Required parameters | Returns |
|---|---|---|
buzzabout__get_me | — | User with account, plan, members, teams |
Pagination model
All list_* tools return:
{
"content": [ /* rows */ ],
"cursor": "eyJ...="
}Pass the cursor back as the cursor argument to fetch the next page. A
null cursor means you've hit the end. Cursors on filtered list
endpoints (mentions, audience profiles) encode the sort dimension, so
don't reuse a cursor across sort changes.
Polling runs
Two things to poll, both covered above:
-
An
askturn →get_message(long-polls; settles atstop_reasonnon-null). -
An existing run's status → the matching
get_*_run(get_dataset_run,get_audience_dataset_run,get_pattern_detection_run) untilstatus.typeiscompletedorfailed. These carry the same status envelope as the REST API:{ "status": { "type": "working", "steps": [ { "name": "scraping", "completed_at": 1714564890 } ] } }
Error shape
Tool errors come back as a JSON object with an error field — same
error_code taxonomy as the REST API:
{
"error": {
"code": "dataset_not_found",
"message": "Dataset not found",
"status": 404
}
}Match on code (stable); show message to humans. status mirrors
the HTTP status the equivalent REST call would return.
Next steps
- Use in your agent — wire MCP into Claude, Claude Code, Codex, Cursor, ChatGPT, or your own SDK.
- Reference types — how
references[]and inline post links resolve. - API reference — the REST surface, including programmatic CRUD.