Show HN: ContextVM – Running MCP over Nostr
4 comments
I just learned yesterday that ChatGPT (and maybe others) can’t connect to a MCP running on localhost; it needs an endpoint on the public internet. (I guess because the request comes from OpenAI servers?)
I’d rather not expose a private MCP to the public, so ContextVM sounds like a step in the right direction. But I’m confused about how it is called: doesn’t OpenAI’s servers still need you to provide a public endpoint with a domain name and TLS? Or does it use a Nostr API?
I’d rather not expose a private MCP to the public, so ContextVM sounds like a step in the right direction. But I’m confused about how it is called: doesn’t OpenAI’s servers still need you to provide a public endpoint with a domain name and TLS? Or does it use a Nostr API?
Interesting, I didn't know about that. It could be for security reasons or to lock users into their platform tools, but it seems odd.
If you can still connect to a stdio MCP server, you can plug it into a remote MCP server exposed through ContextVM. You can do this using the CVMI CLI tool, or if you need custom features, the SDK provides the primitives to build a proxy. For example, using CVMI, you could run your server over Nostr. You can run an existing stdio server with the command `npx cvmi serve -- <your-command-to-run-the-server>` or a remote HTTP server with the command `npx cvmi serve -- http(s)://myserver.com/mcp`. This makes your server available through Nostr, and you will see the server's public key in your terminal.
Locally, you can then use the command `npx cvmi use <server-public-key>` to configure it as a local stdio server. The CLI binds both transports, Nostr <-> stdio, so your remote server will appear as a local stdio server. I hope this clarifies your question. For more details, see the documentation at https://docs.contextvm.org. Please ask if you have any other questions :)
If you can still connect to a stdio MCP server, you can plug it into a remote MCP server exposed through ContextVM. You can do this using the CVMI CLI tool, or if you need custom features, the SDK provides the primitives to build a proxy. For example, using CVMI, you could run your server over Nostr. You can run an existing stdio server with the command `npx cvmi serve -- <your-command-to-run-the-server>` or a remote HTTP server with the command `npx cvmi serve -- http(s)://myserver.com/mcp`. This makes your server available through Nostr, and you will see the server's public key in your terminal.
Locally, you can then use the command `npx cvmi use <server-public-key>` to configure it as a local stdio server. The CLI binds both transports, Nostr <-> stdio, so your remote server will appear as a local stdio server. I hope this clarifies your question. For more details, see the documentation at https://docs.contextvm.org. Please ask if you have any other questions :)
this looks great, will need to give it a go!
how do you see the skills vs mcp playing out in relation to this tho?
how do you see the skills vs mcp playing out in relation to this tho?
Hey! Thanks :)
From my perspective Skills and MCP complement each other: skills orchestrate tasks, while MCP implements them. This synergy has been explored in some articles and the recent MCP code mode trend. MCP serves as a standard for capability execution, and skills aid in progressive disclosure and token saving. I've also seen a trend of exposing skills as MCP resources using the 'skill://' prefix.
Different working groups are leveraging MCP's standardness to save tokens, such as using an MCP server with just 'search' and 'execute' tools.
On the CVM side, we're developing CVMI, a CLI tool for installing CVM related skills and serving or using servers as regular MCPs. Soon, CVMI will also enable calling CVM servers, allowing you to create scripts using just bash and CVMI
From my perspective Skills and MCP complement each other: skills orchestrate tasks, while MCP implements them. This synergy has been explored in some articles and the recent MCP code mode trend. MCP serves as a standard for capability execution, and skills aid in progressive disclosure and token saving. I've also seen a trend of exposing skills as MCP resources using the 'skill://' prefix.
Different working groups are leveraging MCP's standardness to save tokens, such as using an MCP server with just 'search' and 'execute' tools.
On the CVM side, we're developing CVMI, a CLI tool for installing CVM related skills and serving or using servers as regular MCPs. Soon, CVMI will also enable calling CVM servers, allowing you to create scripts using just bash and CVMI
I started building ContextVM some months ago, this is an open protocol that runs the Model Context Protocol (MCP) over Nostr.
In practice, it’s a transport for MCP that lets you expose remote servers without needing a domain, inbound ports, or OAuth, clients, and servers only need an outbound internet connection.
The problem I ran into: When deploying a remote MCP server you can feel the pain. You usually need a domain name, a static IP, TLS certificates, port forwarding, and some way to auth (often OAuth). That friction makes it hard to spin up a service on your laptop or a Raspberry Pi and expose it safely.
ContextVM solves this at the transport layer. It replaces HTTP/SSE with Nostr relays that act like a distributed, stateless message bus:
Identity/auth: public keys instead of OAuth.
Network/transport: clients and servers only need outbound connection to relays, so you can run behind NAT or a strict firewall.
Security: client↔server traffic is end-to-end encrypted; relays just route encrypted events blindly.
Addressing/discovery: servers (and clients) are addressable by public key, no domains required. Servers can be announced on relays instead of central registries. Private servers can skip announcements entirely, clients connect if they know the server’s public key.
Payments: Recently we included a payment method agnostic specification defining the lifecycle of payments, this is CEP-8 https://docs.contextvm.org/spec/ceps/cep-8/
The best part, you don’t need to rewrite your existing MCP servers:
- `cvmi`: a CLI to expose any local HTTP/Stdio MCP server over ContextVM. For example, `npx cvmi serve -- npx -y @modelcontextprotocol/server-filesystem /tmp`
- `ctxcn`: inspired by `shadcn/ui`. It connects to a server, reads its MCP schema, and generates a type-safe TypeScript client into your codebase.
- TypeScript SDK: for those who want to build natively on the protocol.
- Project site: It works as a tool for discovery, and debugging, you can run your server locally and connect through the site
We'd love feedback, questions, or critiques. If you want to dig deeper, you can visit the project page for a blog, read the docs, or just build something. It's all open source, permissionless, and fun!
We are also publishing a bi-weekly newsletter on substack: https://contextvm.substack.com/
Code: https://github.com/contextvm
Project site: https://contextvm.org
Docs: https://docs.contextvm.org