DPYC Oracle
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| aboutA | Extended narration about DPYC, the Social Contract, and the Oracle. Fetches README.md and GOVERNANCE.md from the dpyc-community repo and assembles a comprehensive context answer. |
| lookup_memberA | Look up a member by their Nostr npub. Can look up any role's npub — citizen, operator, or authority. Returns the full member record if found, or a not-found message. |
| get_tax_rateA | Explain how Tollbooth certification taxation works. Taxation is ad valorem and per-Authority — there is no single
network-wide number, and the Oracle deliberately quotes none. The
actual fee is the Authority's own accounting, set in its pricing model
and reported at transaction time. This tool is a docent: it explains
the model and points to the live source. For the exact figure, query
the relevant Authority's |
| economic_modelA | Explain the DPYC Social Contract economic model — qualitatively. Describes how value flows through the network: ad valorem certification fees, the cascade up the Certification Chain to the First Curator, and where the live numbers actually live. The Oracle quotes no rates, counts, or revenue figures — those belong to the Authorities' pricing models and the live registry, not to a docent. Free, unauthenticated. |
| get_rulebookA | Fetch the DPYC Social Contract governance document. Returns the raw markdown of GOVERNANCE.md from the dpyc-community repo. |
| how_to_joinA | Tier-specific onboarding guide for joining the DPYC Social Contract. Covers all five tiers: Citizen, Advocate, Operator, Authority, and First Curator. Includes Nostr keygen instructions and practical next steps. |
| who_is_first_curatorA | Identify the First Curator (Prime Authority) of the Certification Chain. Returns the curator's npub, display name, and member record. |
| network_versionsA | Get current recommended versions of all Tollbooth components. Returns component versions, minimum compatibility, active protocols, and a short advisory summary. Data is fetched live from network-status.json in the dpyc-community repo. |
| network_advisoryA | Get current network deployment advisory. Returns human-readable guidance on what changed recently, urgent upgrades, and actions operators should take. Fetched live from ADVISORY.md in the dpyc-community repo. |
| how_to_add_authorityA | End-to-end guide for spinning up a new Tollbooth Authority. Returns the eight-step procedure covering identity, region selection, GitHub workspace, dpyc-community registry entry, Neon + BTCPay + Horizon deployment, BTCPay credential delivery via Secure Courier, the self-registration challenge-response with the parent Authority, and pre-funding the cert-fee balance. Fetched live from docs/how-to-add-authority.md in the dpyc-community repo. |
| service_statusA | Diagnostic: report this service's software versions and runtime info. Free, unauthenticated. Use to verify deployment versions across the DPYC ecosystem. |
| list_servicesA | Enumerate the live DPYC service network with self-described summaries. Reads the member roster from the dpyc-community registry, then (when
Resilient by design: per-service timeout, partial results, brief caching, and a registry-only fallback when an endpoint is asleep or unreachable. A sleeping service never breaks the listing. Free, unauthenticated. |
| get_relaysA | Return the DPYC Nostr relay set, best first. The single source of truth is That file is a curated guess: it says which relays are worth using, not which are up this minute. Relays that an operator reported and the Oracle then proved unreachable are moved to the back of the list; everything else keeps its declared order, and nothing is ever dropped. This call never probes anything — it is on every operator's cold-start
path, so it stays a lookup. Ranking improves only when someone hits a dead
relay and says so via Free. |
| report_relay_failureA | Report that a relay in the DPYC set was unreachable, and re-rank it. A report does not set a relay's rank. It asks the Oracle to measure that relay now, and the Oracle's own probe decides. A false or mistaken report therefore costs one probe and changes nothing — no caller can demote a healthy relay by asserting that it is down. Report only failures. Successes are far too frequent to be worth carrying, and a relay that works needs no announcement. |
| resolve_authority_forA | Resolve the certifying Authority for an operator npub. Returns the Authority's |
| resolve_serviceA | Resolve a DPYC service by Returns |
| request_citizenshipA | Begin the citizen registration process (Operator-owned flow). This is the citizen registration path. Called by the Operator on behalf of a patron — invokes the Oracle directly. No Authority npub is required or consulted. The patron's npub is registered as a Citizen in the DPYC community. The npub provided here becomes the user's patron identity — the keypair they will use for credit purchases and service access across all Tollbooth-monetized services. Not to be confused with operator registration, which goes through the Authority via a Nostr DM delegation request. Issues a cryptographic challenge that the applicant must sign with their Nostr private key (nsec) to prove they own the claimed npub. The nsec never leaves the applicant's device. Returns a challenge_id, nonce, and signing instructions. The applicant signs a Nostr event containing the nonce and submits it via confirm_citizenship within 10 minutes. |
| confirm_citizenshipA | Complete the citizen registration by submitting a signed Nostr event. This is part of the citizen registration flow (Operator-owned). The Operator calls this on behalf of a patron after the patron has signed the cryptographic challenge from request_citizenship. Verifies:
On success, commits directly to dpyc-community/members/citizens/{npub}.json to register the new Citizen immediately. |
| register_authorityA | Register a new Authority in the DPYC community registry. Called by an Authority service at the end of the onboarding protocol
(after the candidate proves npub ownership and the Prime Authority
approves). Commits a new The full Authority onboarding protocol is a 3-step Nostr DM challenge-response flow:
|
| register_operatorA | Register a new Operator in the DPYC community registry. Called by an Authority service after the operator requests registration. The Authority validates the operator's identity and sponsors the registration by calling this tool via MCP-to-MCP. |
| update_operatorA | Update an existing Operator's registry entry. Used when an Operator moves to a new MCP endpoint, changes its display name, or needs to correct a registration. Must be called by the sponsoring Authority (or any Authority). |
| deregister_operatorA | Remove an Operator from the DPYC community registry. Called when an Authority disowns an Operator. An Operator cannot exist without a sponsoring Authority, so deregistration removes the member file entirely, returning the Operator to initial state. |
| register_advocateA | Register a new Advocate in the DPYC community registry. Advocates are community utility services that provide shared infrastructure (e.g., OAuth2 callback collectors) but aren't monetized Operators or certification Authorities. This is an Oracle-mediated registration — no Nostr DM challenge-response needed. The Oracle operator (Prime Authority) trusts the commit via GitHub token. |
| check_ban_statusA | Check whether an npub is banned from the DPYC Social Contract. Looks up the member in the community registry and checks whether their status is "banned". Unknown npubs are not considered banned (they simply aren't members). Free, unauthenticated. Used by operators during the cold path (credit purchases) to enforce community bans. |
| renounce_membershipB | Citizen self-removal from the DPYC Social Contract via automated PR. Not yet implemented — will create a GitHub PR to remove the member from the registry. |
| initiate_ban_electionB | Initiate a community ban election against a member. Not yet implemented — will create a GitHub Issue with a 72-hour discussion period and Lightning-funded economic voting. |
| cast_ban_voteA | Cast a Lightning-funded vote in an active ban election. Not yet implemented — will verify npub membership, validate the election is active, and record the vote with a Lightning payment proof. |
| publish_campaignA | Publish a pricing campaign to the DPYC community. Commits both a machine-importable JSON file and a human-readable Markdown summary to the dpyc-community campaigns directory. |
| list_campaignsA | List published pricing campaigns from the DPYC community. Optionally filter by operator or author npub. |
| get_campaignB | Retrieve a published pricing campaign. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 30 tools
Each tool targets a distinct resource and action—member lookups, role-specific registrations, relay management, campaigns, and informational queries are all clearly separated. Even the 'not yet implemented' ban and membership tools are unambiguous in their purpose.
The majority of tools follow a verb_noun pattern (get_rulebook, register_operator, list_campaigns), but a substantial minority use bare nouns or phrases (about, economic_model, network_versions, how_to_join, who_is_first_curator, service_status). This mix is readable but inconsistent.
With 30 tools, this exceeds the 25+ threshold that signals an overgrown surface. The broad scope—membership, authorities, operators, advocates, bans, campaigns, relays, and network info—partly justifies the count, but the set feels heavier than necessary and could be consolidated.
The tool surface covers the core lifecycle for citizens, operators, authorities, advocates, campaigns, and relays, plus governance and network status. Minor gaps exist—no advocate deregistration, no citizen update flow, and some ban tools are stubs—but agents can complete primary workflows.