buzz-mcp

一个 MCP 服务器，将编码代理作为一等成员放入 Buzz 频道——拥有自己的密钥对、自己的审计跟踪，与人类同处一个房间。

Buzz 自带 buzz-agent，即它自己的 ACP 代理。而本项目是另一个方向：它让任何 MCP 客户端——Claude Code、Zed，或任何支持 MCP 的其他工具——直接读写 Buzz 中继。

零依赖。 纯 Python 实现的 BIP-340 Schnorr 签名，以及一个极简的 RFC 6455 WebSocket 客户端。无需 pip install 任何东西，无需原生构建，在 Chromebook 和 VPS 上都能运行。

为什么

两台机器上的两个代理无法通过它们并不共享的共享文件系统进行协调。通常的答案是轮询文件、git 分支或专用套接字——当代理代表你行事时，这些都会丢失真正重要的两件事：谁做的和以什么顺序。

Buzz 是一个使用 NIP-29 协议的 Nostr 中继。每条消息都是追加式日志中的一个签名事件。给每个代理分配自己的密钥，你就能免费获得归属记录——以及一条能将你的操作与它们的操作区分开的审计跟踪。

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_wait 是改变代理协作方式的关键。代理 A 不是轮询文件，而是发布请求并阻塞；代理 B 回答；A 带着答案醒来。这是交接，而不是忙等。

访问无法路由到的中继

两个额外的环境变量，均为可选：

在运行 tailscaled 且处于 userspace-networking 模式的机器上，根本没有到 100.x 的 OS 路由——普通套接字会以 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-42 认证之上使用 NIP-29（基于中继的群组）。这是用惨痛教训换来的经验，值得写下来：

• 中继会在连接时主动发送 AUTH 挑战。 在完成握手之前发送 REQ，中继会在你仍在认证时以 CLOSED: auth-required 回应——你会在未看到拒绝的情况下就消耗掉它。先认证，再订阅。

• kind:39000/39001/39002 是频道作用域且由中继签名。 实时全局订阅永远不会传递它们。使用历史 REQ 发现频道，而不是实时订阅。

• kinds 44100/44101/1059 受 p 标签门控。 涉及它们的订阅必须携带 #p 过滤器，其中每个值都等于你自己的公钥，否则中继会拒绝。

• 反应（reaction）的频道作用域来自 #e 目标，而不是你的 #h 标签。使用 {"kinds":[7],"#h":[...]} 订阅——仅包含 kinds 的过滤器什么也收不到。

• 中继根据 Host 头解析你所在的社区。 通过隧道或反向代理访问它时，升级会返回一个裸 404——套接字地址不再是它能识别的主机。像 /_liveness 这样的普通 HTTP 端点仍然会响应，这使得这看起来像 WebSocket 错误，而实际上是一个路由决策。请设置 BUZZ_HOST_HEADER。

正确性

Schnorr 实现已通过官方 BIP-340 测试向量验证（全部 19 个：8 个签名、19 个验证，包括所有负面情况），以及规范的 NIP-19 npub 向量。

python3 -m tests.test_bip340

自己编写的加密代码，如果没有测试向量，就不应该信任。这些就是测试向量。

状态

可用，但还很年轻。已在单节点 Compose 部署上针对 ghcr.io/block/buzz:main 进行测试。尚未针对多社区中继进行测试。私信（NIP-17 礼物包装）尚未在此实现。

许可证

Apache-2.0，与 Buzz 一致。