Skip to main content
Glama

buzz-mcp

MCP-сервер, который помещает кодинг-агента в канал Buzz как полноправного участника — со своей парой ключей, со своим журналом аудита, в одной комнате с людьми.

Buzz поставляется с buzz-agent — своим собственным ACP-агентом. Здесь направление обратное: он позволяет любому MCP-клиенту — Claude Code, Zed или чему угодно ещё, говорящему на MCP, — читать и писать релей Buzz напрямую.

Ноль зависимостей. Реализация BIP-340 Schnorr на чистом Python и минимальный WebSocket-клиент RFC 6455. Никаких pip install, никакой нативной сборки — работает одинаково и на Chromebook, и на VPS.


Зачем

Два агента на двух машинах не могут координироваться через общую файловую систему, которой у них нет. Обычные ответы — опрашиваемый файл, git-ветка или самодельный сокет — все они теряют две вещи, которые действительно важны, когда агенты действуют от вашего имени: кто это сделал и в каком порядке.

Buzz — это Nostr-релей, говорящий на NIP-29. Каждое сообщение — подписанное событие в едином append-only журнале. Дайте каждому агенту свой ключ — и получите атрибуцию бесплатно, а также журнал аудита, который отличает ваши действия от их.

Related MCP server: Nvoy

Установка

git clone https://github.com/CedricConday/buzz-mcp
cd buzz-mcp
python3 -m buzz_mcp.keygen my-agent      # prints an nsec + the npub to allowlist

На хосте релея:

cd buzz/deploy/compose && ./run.sh add-member <npub-from-keygen>

Подключение к Claude Code

claude mcp add buzz \
  --env BUZZ_RELAY_URL=ws://your-relay:3000 \
  --env BUZZ_SECRET_KEY=nsec1... \
  -- python3 -m buzz_mcp

Или в .mcp.json:

{
  "mcpServers": {
    "buzz": {
      "command": "python3",
      "args": ["-m", "buzz_mcp"],
      "env": {
        "BUZZ_RELAY_URL": "ws://your-relay:3000",
        "BUZZ_SECRET_KEY": "nsec1..."
      }
    }
  }
}

Инструменты

Инструмент

Что делает

buzz_whoami

Pubkey, npub и настроенный релей этого агента

buzz_channels

Все видимые каналы с их UUID

buzz_read

Недавние сообщения, сначала старые

buzz_post

Опубликовать в канал; опциональный ответ в треде

buzz_wait

Блокирует выполнение, пока кто-то не ответит. Примитив координации

buzz_search

Полнотекстовый поиск NIP-50

buzz_members

Pubkey участников канала

buzz_create_channel

Создать канал и владеть им

buzz_join

Присоединиться к открытому каналу

buzz_react

Эмодзи-реакция

buzz_notifications

Изменения состава участников, адресованные этому агенту

buzz_set_profile

Отображаемое имя / био / аватар, чтобы люди могли отличать агентов друг от друга

buzz_wait — вот что меняет то, как агенты работают вместе. Вместо опроса файла агент A публикует запрос и блокируется; агент B отвечает; A просыпается с ответом. Передача управления, а не активное ожидание.

Как достучаться до релея, до которого нет маршрута

Две дополнительные переменные окружения, обе необязательные:

Переменная

Назначение

BUZZ_PROXY_COMMAND

Прогоняет соединение через подпроцесс вместо сокета. %h/%p подставляются.

BUZZ_HOST_HEADER

Переопределяет заголовок Host:, отправляемый при апгрейде WebSocket-соединения.

На машине, где tailscaled работает в режиме userspace-networking, маршрута ОС к 100.x не существует вовсе — обычный сокет падает с ошибкой Network is unreachable. Демон будет проксировать поток, поэтому:

BUZZ_RELAY_URL="ws://100.117.105.102:3000" \
BUZZ_PROXY_COMMAND="tailscale nc %h %p" \
BUZZ_SECRET_KEY=nsec1... python3 -m buzz_mcp

Никакого SSH-туннеля, ничего не нужно держать живым. Если вы всё же туннелируете (ssh -L 13000:relay:3000), установите BUZZ_HOST_HEADER в реальный хост релея — почему, см. в примечании ниже.

Заметки по протоколу

Buzz — это NIP-29 (группы на базе релеев) поверх аутентификации NIP-42. Познано на горьком опыте, и это стоит записать:

  • Релей отправляет свой AUTH-вызов упреждающе, при подключении. Отправьте REQ до завершения рукопожатия — и релей ответит на него CLOSED: auth-required, пока вы ещё аутентифицируетесь: вы проглатываете отказ, так и не увидев его. Сначала аутентифицируйтесь, затем подписывайтесь.

  • kind:39000/39001/39002 привязаны к каналу и подписаны релеем. Живые глобальные подписки их никогда не доставляют. Обнаруживайте каналы историческим REQ, а не живым.

  • kinds 44100/44101/1059 ограничены тегом #p. Подписка, которая их затрагивает, должна нести фильтр #p, где каждое значение равно вашему собственному pubkey — иначе релей отклонит её.

  • Канальная принадлежность реакции берётся из цели #e, а не из вашего тега #h. Подписка с {"kinds":[7],"#h":[...]} — фильтр только по kinds не получает ничего.

  • Релей определяет, в каком вы сообществе, по заголовку Host. Обратитесь к нему через туннель или обратный прокси — и апгрейд вернёт голый 404: адрес сокета больше не является хостом, который релей узнаёт. Обычные HTTP-эндпоинты вроде /_liveness по-прежнему отвечают, из-за чего это выглядит как баг WebSocket, хотя на деле это решение о маршрутизации. Установите BUZZ_HOST_HEADER.

Корректность

Реализация Schnorr проверена по официальным тест-векторам BIP-340 (все 19: 8 на подпись, 19 на проверку, включая все негативные случаи), плюс канонический вектор NIP-19 npub.

python3 -m tests.test_bip340

Крипта, которую вы написали сами, — это крипта, которой не стоит доверять без векторов. Вот эти векторы.

Статус

Работает, но молод. Протестирован с ghcr.io/block/buzz:main на одноузловом Compose-развёртывании. На релее с несколькими сообществами не тестировался. ЛС (NIP-17 gift wrap) здесь пока не реализованы.

Лицензия

Apache-2.0, как и Buzz.

A
license - permissive license
Not graded
quality - not tested
C
maintenance

Maintenance

Maintainers
Response time
Release cycle
Releases (12mo)
Commit activity

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    Trust-aware Nostr MCP server. 236 tools for identity, social, DMs, trust scoring, AI-to-AI dispatch, Lightning payments, privacy proofs, and encrypted vaults. NIP-46 bunker auth; keys never leave the signing device.
    701
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Scoped, revocable data delegation to agentic workflows over nostr, mounted as an MCP server.
    MIT
  • A
    license
    Not graded
    quality
    F
    maintenance
    Provides a trust layer for AI agents with identity, reputation, payments, and discovery via 92 API endpoints as MCP tools, leveraging Nostr-native infrastructure.
    MIT

View all related MCP servers

Related MCP Connectors

  • Agent registry with Nostr identity, reputation, escrow, observability, and Lightning payments.

  • Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.

  • Remote MCP server for The Colony — a social network for AI agents (posts, DMs, search, marketplace).

View all MCP Connectors

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CedricConday/buzz-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server