RFC: community-level MCP server announcements via a new Nostr event kind

[marcellodesales]

💡 Feature Request / RFC

We're building a shared agent memory and tool-discovery layer on top of a Buzz relay deployment, and hit a design question worth raising upstream: should the relay support community-scoped MCP server announcements as first-class Nostr events?

---

🎯 Problem

Today, MCP (Model Context Protocol) server configuration is per-developer-machine. Each Claude Code session (or any agent using MCP) reads its tool list from a local settings.json. Two developers in the same Buzz channel, using the same agent, get different tool availability — silently. There is no community-level truth for "which tools are available here."

---

🔍 What we built as a workaround

We want to store MCP server config in a Buzz git repo (vionix/mcp-registry, NIP-34 kind:30617) and have the buzz-acp pull that at startup. If that works as a workaround — it requires a git pull, a startup code change in buzz-acp, and manual repo provisioning per community.

---

💬 Upstream design question

Would it make sense to add a new parameterized replaceable event kind for MCP server announcements, scoped to a community?

Sketch (kind number is a placeholder):

{
  "kind": 39000,
  "content": "{\"url\":\"https://engram.example.com/mcp\",\"capabilities\":[\"memory/query\",\"memory/ingest\"]}",
  "tags": [
    ["d", "vionix-engram"],
    ["community", "<community-id>"],
    ["name", "Vionix Engram"],
    ["description", "Temporal knowledge graph memory for this workspace"]
  ]
}

Agents subscribing to a community would receive MCP server announcements automatically — no git pull, no startup-time buzz-acp changes. Adding or removing a tool from a workspace would be a relay admin event, visible to all connected agents in real time.

---

🤔 Questions for maintainers

1. Is community-level tool/capability discovery something on the Buzz roadmap?
2. Would this be better as a relay-managed endpoint (GET /community/mcp-servers) rather than a Nostr event kind?
3. Is there an existing NIP or proposed NIP that covers this? (NIP-90 DVMs are in the space but don't map cleanly to always-on MCP servers.)
4. Any concern about security model — an agent in a community auto-inheriting MCP servers announced by any community admin?

---

🌍 Context

We're using this in a scenario where:

• A Buzz community maps to an engineering team
• The team has shared MCP servers for K8s, memory/knowledge graph, CI, and internal APIs
• Agents (both human-operated Claude Code sessions and autonomous buzz-acp instances) should all get the same tool set when operating in that community
• The MCP registry connects to a kagent (A2A) agent infrastructure where the actual tool implementations run in-cluster

Happy to discuss the design further or prototype if there's interest.

[rodriguezrussell93]

依赖版本锁定策略是怎么考虑的 🙌👍

[wolfyy970]

I would keep discovery separate from launch authority. I am implementing portable logical tool requirements plus explicit Project-local bindings, while commands, URLs, credentials and executable approval stay on the operator's device.

A Nostr event could advertise that a capability is available, but it should not auto-inject an MCP server into agents. That gives a community one discoverable catalog without silently granting tools or publishing credentials. #4164 is the resolved launch document, and #4588 is the local connection boundary.