A universal plug is useful only if you can find the socket.
The Model Context Protocol gives AI applications a shared interface for tools and data. In a local setup, discovery is almost invisible: the user supplies a server address or a configuration file, and the client knows where to connect.
Move that same interaction onto an open network and the convenient assumptions disappear. A server needs to announce that it exists. A client needs to understand the announcement. Both sides need to agree on capabilities, identity, and transport behavior—without depending on a registry owned by one company.
That is the problem space behind ContextVM’s MCP-over-Nostr stack. My contributions crossed three layers of it: the SDK that carries and discovers services, the trust service that interprets relationships, and the product that turns both into a usable tool experience.
A protocol does not end at the wire. Every ambiguity eventually becomes a product state.
A Protocol Still Needs a Directory
Imagine arriving in a new city with a universal electrical adapter. It can connect to any socket—but it cannot tell you where a socket is, whether it works, or who operates it. Compatibility solved only one part of the problem.
Decentralized AI tools have the same gap. Nostr relays can carry signed events between participants, giving servers a shared place to announce themselves without one canonical database. But “broadcast and hope” is not discovery. Clients still need predictable event shapes, stable tags, useful metadata, and consistent behavior across different relay connections.
A small inconsistency here travels surprisingly far. A discovery event published to the wrong implicit relay can make a local test behave like a public network. A malformed tag can turn a working service into an invisible one. A duplicated metadata event can confuse tests that expected only a transport response.
Teaching a Server to Introduce Itself
An address answers “where.” It does not answer “what.” Before connecting, a person or an agent needs to know the server’s name, description, and advertised capabilities.
CEP-23 adds that introduction. I implemented server-profile metadata publication in the ContextVM SDK so an MCP server can describe itself through signed Nostr metadata. The profile is intentionally more than decoration: it gives discovery interfaces enough information to explain what a server is before asking a user to trust or invoke it.
I also fixed relay publication behavior so discovery is deterministic across connection modes. Implicit public bootstrap relays should not quietly appear in a local or in-memory setup. Predictability matters because tests and development environments are part of the protocol’s usability—not separate from it.
Can two independent clients look at the same signed event and reach the same conclusion about what the server offers? If not, the metadata is not yet a protocol.
Reliability Often Looks Boring
Some of the most valuable infrastructure work is deliberately uneventful. It removes surprises instead of adding a visible feature.
ContextVM already had support around oversized transfers. My work split the transfer helpers, relay resolution, and discovery-tag logic into focused internal modules, removed dead paths, and corrected capability gating without expanding the public API. The outcome was not a new button. It was code whose boundaries match the protocol’s responsibilities more closely.
The same principle applied to tests. Several asynchronous assertions were not awaited, which meant a test could appear successful while the promise containing its real expectation was still unresolved. Adding the missing awaits closed that gap between green output and actual confidence.
These changes form one reliability story: publish the right metadata, publish it to the right places, keep transport responsibilities separable, and make the tests wait for the behavior they claim to verify.
Trust Is Personal, Not Universal
Discovery answers “what is available?” It does not answer “what should I use?” A centralized marketplace often responds with one global ranking. An open network cannot assume that the same ranking is right for everyone.
Relatr approaches trust as a path through relationships. It combines Nostr social-graph distance with profile and identity signals, then exposes the result through an MCP service. DuckDB provides local persistence and caching; a plugin model allows validation logic to evolve without turning the core service into one fixed definition of trust.
This does not make malicious services disappear, and a score is not proof of safety. It gives a client contextual evidence: how a service relates to the user’s network and which signals informed the result. That is a more honest abstraction than a universal number presented without provenance.
The Last Mile Is Product State
A correct protocol can still feel broken if the product forgets what happened.
In the ContextVM web client, I worked on API-key persistence, model-loading behavior, and MCP tool-registry invalidation when servers connect or disconnect. These sound like interface details. They are really consistency problems.
If the registry remains stale after a disconnect, the agent may believe a tool exists when it does not. If an empty API key still triggers a model request, the interface turns a configuration state into a confusing network failure. If a valid key is not persisted, every session begins by making the user rebuild context the product already had.
The orchestration loop depends on the whole chain being honest: the signed event describes the server, the SDK resolves its capabilities, the registry reflects the live connection, and the interface shows the user what the agent can actually do.
One Reliability Chain
Working across the SDK, Relatr, and the client changed how I think about infrastructure. Transport, trust, and interface are not independent products. They are one reliability chain.
A malformed tag at the protocol layer can become an invisible server. A stale registry can become an agent calling the wrong tool. A test that passes without awaiting its assertion can turn either bug into false confidence.
Open-source contribution is not about claiming an entire system. It is about understanding the boundaries well enough to make several of them more dependable.