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

## 💡 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):

```json
{
"kind": 39000,
"content": "{\"url\":\"https://engram.example.com/mcp\",\"capabilities\":[\"memory/query\",\"memory/ingest\"]}",
"tags": [
["d", "vionix-engram"],
["community", ""],
["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.