A location and delivery layer for MCP servers on a virtual local network — single source of truth, no sync.
Run an MCP server on your desktop and you can only reach it from that desktop. Run a second copy on your laptop and you now have two of everything: two databases, two histories, and a merge problem nobody asked for.
p2p-mcp takes the other branch. It keeps one authoritative instance per
service and answers two questions for everyone else: where does the single
source of truth for this service live, and how do I reach it. Writes are
delivered there. Nothing is replicated, mirrored, or reconciled.
Think of it as a NAS rather than a sync service. A NAS does not make your files "eventually consistent" across machines — it just makes one copy reachable from all of them.
p2p-mcp expects to run inside a virtual local network: an authenticated
overlay in which every participating machine behaves as if it shared a LAN with
the others. Concretely, the network layer must provide
- stable naming — a hostname that resolves to the right machine without a central directory you have to operate,
- authenticated membership — the network decides who is allowed in; this project never sees a credential,
- direct reachability — machines reach each other across NAT without a relay you configure, and
- transport encryption — traffic is protected before it reaches this layer.
Tailscale is the first target and what the v0 code paths are written against — MagicDNS supplies the naming, the tailnet supplies membership and reachability. Anything that satisfies the same contract works just as well: Headscale, NetBird, ZeroTier, Nebula, or a WireGuard mesh you maintain yourself. The contract above is the interface; Tailscale is one implementation of it.
What this project will never grow: transport, NAT traversal, hole punching, relay networks, identity, authn/authz, ACLs, certificate or key management, VPN/tunnel implementations, or backup machinery. Those belong to the network layer, permanently.
1. Location guarantee only. The system tells you where the single source of truth is and gets your write there. It does not replicate or reconcile state. Bidirectional multi-writer is forbidden by design — no sync loops, no last-writer-wins merges, no CRDTs, no replica sets. If a proposal needs two machines both accepting writes for one service, it is out of scope rather than a feature request.
2. Full delegation to the network layer. See above. Networking, authentication, tunnelling, and backup are somebody else's problem, and keeping them that way is what makes this layer small enough to trust.
3. A write always reaches the single SoT. Every path that accepts, queues, forwards, or retries a write terminates at the one authoritative instance. A write that lands anywhere else — a local cache treated as authoritative, a second accepting node, a silently dropped queue entry — is a bug, not a degraded mode. When the SoT is unreachable, the write waits in an outbox or fails loudly; it is never accepted locally as though it had landed.
p2p-mcp/ <- workspace root (virtual manifest)
└── crates/
├── core/ <- package `p2p-mcp-core` (embeddable SDK lib)
└── mcp/ <- package `p2p-mcp` (MCP server binary)
p2p-mcp-core is the embeddable half: depend on it directly to give an existing
MCP server a location/delivery layer. p2p-mcp is the standalone server binary.
Planned modules: core (config + hello handshake) / discover (peer and
service discovery) / serve (streamable HTTP surface + a bind guard that
refuses to listen outside the virtual network) / relay (outbox, forward,
trace) / mediate (structured conflict reporting) / cli.
v0 bootstrap — scaffold only. Nothing is implemented yet; both crates are compiling stubs.
v0 scope: core config (a node is either the sot or a client for a given
service) and the hello handshake (identity, service list, schema hash, SoT
claim); serve glue with a bind guard that only binds inside the virtual
network; static discovery from a configured hostname; and integration into
mini-app-mcp through a --serve mode
that leaves its existing tools untouched.
v1 adds relay (outbox, forward, trace) and the CLI. v2 adds peer relay,
discover against the network layer's own API, mediate, and the decision on
whether to publish to crates.io.
Minimum supported Rust version: 1.85 (edition 2024).
Dual-licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE)
- MIT License (LICENSE-MIT)
at your option.