p-e-relay
Related Servers
Alternatives to p-e-relay
No user-submitted related servers found.
Related Servers
- AlicenseAqualityBmaintenanceA read-only MCP server for safely exploring Nostr, enabling agents to resolve identifiers, fetch profiles and events, query notes, and inspect relay metadata. It does not accept private keys or publish events.56 npmMIT
- AlicenseAqualityFmaintenanceRead-only ProofRelay MCP verifier for non-confidential evidence bundles. Exposes 22 public-safe tools, 11 resources, and 11 prompts for bundle integrity checks, receipt-chain review, checkpoint recommendations, MCP risk metadata review, and real-estate closing proof-pack readiness.5MIT
- AlicenseNot gradedqualityCmaintenanceRead-only MCP server that provides tools to fetch SealChat public protocol docs, manifest, channel counts, and chat messages via the HTTP Agent API, without write access or database access.MIT
- AlicenseNot gradedqualityAmaintenanceServes as a catalog that probes and lists reachable MCP relays, letting agents discover relays, search their tools, and call any tool through a single REST, MCP, or webhook endpoint. It also signs webhook notifications for relay registration, updates, and online/offline changes, and can peer with other catalogs to extend what is listed.0MIT
- AlicenseNot gradedqualityAmaintenanceA local, read-only MCP server that exposes verified profile, posts, corpus, and other identity data from robertdelanghe.dev's signed static API.19 npmMIT
- AlicenseNot gradedqualityCmaintenanceRead-only, keyless MCP access to weir.social: search, quote, read, verify authorship and look up agents. Run locally with an operator's own key it adds buy, subscribe, publish and send.518 npmApache 2.0
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose: get_relay fetches bytes, exists checks state, list_relays surveys all ids, list_replies finds records referencing an id, append_relay writes, and wait_for_relay blocks for new records. Even the superficially overlapping get_relay and exists are explicitly delineated by what they return.
Most tools follow a clear verb_noun pattern: get_relay, append_relay, wait_for_relay, list_relays, list_replies. The bare 'exists' breaks the pattern slightly, but it is still readable and predictable in context.
Six tools is well-scoped for an append-only relay store: one write, one blocking wait, and four distinct read/query operations. Each tool earns its place with no redundant or excessive surface.
The surface covers the full lifecycle for this domain: append creates records, get_relay retrieves bytes, list_relays enumerates holdings, exists checks specific ids, list_replies navigates references, and wait_for_relay supports polling without tight loops. The intentional absence of delete/update is consistent with the append-only design.