Bardo

Identity & continuity for AI agents, gated by a proof-of-being-an-LLM puzzle.

CommunityOnlineNo sign-inGlobalFreeRead-only

What it can do

    What data it sees

    Do you need an account

    No: the server works without sign-in

    Identity & continuity for AI agents, gated by a proof-of-being-an-LLM puzzle.

    How to connect

    How to connect Bardo to Claude

    The server address to paste into Claude settings:

    https://bardo.id/mcp/

    1. Open Claude (claude.ai or the desktop app).
    2. Go to Settings → Connectors.
    3. Click Add custom connector.
    4. Paste the server address copied below into Remote MCP server URL and click Add.
    5. In a chat, click + → Connectors and switch the new connector on.

    Custom connectors are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). On Team and Enterprise an organization Owner adds the connector first under Organization settings → Connectors.

    Authorization

    After you click Add, a sign-in window for the service opens. Sign in with your own account and approve access. Claude never sees your password.

    How to connect Bardo to ChatGPT

    The server address to paste into ChatGPT settings:

    https://bardo.id/mcp/

    1. Open ChatGPT in a browser (chatgpt.com). A Plus, Pro, Business, Enterprise or Edu plan is required.
    2. Turn on developer mode once: Settings → Apps → Advanced settings → Developer mode.
    3. Open Settings → Connectors and click Create.
    4. Fill in the form: Name (anything), Description (one line about what the service does), MCP server URL (copy it below).
    5. Under Authentication choose OAuth if the service requires sign-in, otherwise None. Click Create.
    6. In a new chat open + → Apps/Connectors and enable the connector.

    OpenAI has renamed this section before (Connectors → Apps/Plugins). If the label differs, search settings for "developer mode". On Business/Enterprise workspaces an admin must allow custom connectors first.

    Authorization

    On first use ChatGPT opens the service's sign-in window. Sign in and approve access.

    How to connect Bardo to Cursor

    The server address to paste into Cursor settings:

    https://bardo.id/mcp/

    Fastest: click Open in Cursor below and confirm the prompt.

    Manually:

    1. In Cursor open Settings → Cursor Settings → MCP and click Add new global MCP server.
    2. Paste the JSON copied below into ~/.cursor/mcp.json (per project: .cursor/mcp.json in the repo root).
    3. Save the file. The server appears in the MCP list; authorize it there if asked.

    Authorization

    If the service needs sign-in, an authorize button appears next to the server in the MCP list.

    Server tool list (40)

    Raw names from tools/list. Only developers need these.

    bardo_verifyVerify a signature over a UTF-8 message. Public utility (no session).
    bardo_encryptSealed-box encrypt a UTF-8 plaintext to a recipient's encryption public key.
    bardo_document_statusCheck whether a signed document is revoked. `id` is the document's own top-level `id` field (a ni:// URI) — the same thing credentialStatus.id (BardoRevocationCheck) points at. Safe to cache a "not revoked" answer for a while (see the response's own Cache-Control) rather than re-checking on every use.
    bardo_document_revokeRevoke a document you issued. Proof is a fresh signature over 'revoke:' + the document's id, verified against the key its id already committed to, not an account lookup (Bardo never stored the document to look up in the first place) — this still needs no session at the protocol level, only a valid signature. document: the full signed document, exactly as issued (id and proof both still attached) — resubmit it unmodified, don't strip fields yourself. signature_b64: omit it and this signs automatically through your active session instead — pass `service` too if the document was issued under a service-derived key rather than root, since the signature has to come from the exact key the document's issuer field names. Supply signature_b64 yourself only when revoking without a Bardo session at all: you signed it some other way, or you're a party that's never touched Bardo. Idempotent — revoking an already-revoked id is a no-op, not an error. Irreversible: there is no un-revoke.
    bardo_signSign a UTF-8 message with the spirit key (or a service-derived key).
    bardo_decryptDecrypt a sealed-box ciphertext addressed to you (root or service key).
    bardo_public_keyFetch your signing + encryption public keys (root, or for a service).
    bardo_deriveDerive (and register) a service-scoped identity, e.g. 'github.com'.
    bardo_services_listList service-scoped identities you've already derived (bardo_derive), with their public keys and revoked status.
    bardo_exportExport the raw spirit key (subject to policy). Handle with care. Only needs a step-up puzzle if your policy's export_mode is require_repuzzle — checked automatically, so you don't need to know your own policy first. If challenge_id and answer are omitted and one turns out to be needed, a fresh puzzle is returned instead of failing outright — solve it yourself, then call this tool again with both parameters. Never needed under export_mode 'allow'; always fails under 'disabled', with no puzzle that could fix that.
    bardo_attestation_issueAssemble and sign a verifiable attestation — a self-contained, offline-verifiable claim about anything. The document itself is handed back, not stored anywhere (same as bardo_sign itself — there's no bardo_documents_list); see keep_copy below if you want Bardo to save one for you rather than doing it yourself. claim: free-form claim content — whatever you're asserting. Include a `reference` key inside it when cross-referencing another document's id (or any other content, hashed the same ni:// way) — that's how independent attestations end up pointing at "the same thing," e.g. several agents witnessing one event under a shared reference. subject_id: the did:key the claim is about, if it concerns one specific identified party — leave it unset when it doesn't; a bare self-referential claim ("this document is about its signer") is still valid without it. expires_at: unix timestamp for time-boxed claims only; omit for a claim that never expires. service: same key-selector bardo_sign takes — a document meant to represent one specific relationship should use that relationship's service-derived key, not your root identity. keep_copy: save the full document into a locked note right after issuing it — the copy you'd otherwise have to make yourself, and the one you'll need later: bardo_document_revoke takes the whole document, not just its id, since Bardo never stores one itself. Off by default. When true, the return shape changes to {document, copy_saved, note_id, copy_error} instead of the bare document — check copy_saved rather than assume it worked; a failed copy never blocks the document itself from being returned, since issuing has already fully succeeded by that point regardless. To revoke later: bardo_document_revoke. To check whether one you're holding (yours or someone else's) is still valid: bardo_document_status.
    bardo_sessions_listList your active sessions (sliding TTL, absolute 24h cap each).
    bardo_session_revoke_currentRevoke the session you're using right now. You'll need bardo_login (+ bardo_solve) again afterward to do anything session-gated.
    bardo_sessions_revoke_allRevoke every active session for your identity — e.g. after a suspected API-key leak. You'll need to log in again afterward.
    bardo_stepupMint a fresh step-up puzzle for a privileged action (currently: bardo_policy_set). Solve it yourself, then pass challenge_id + your answer to the tool that needs it. (bardo_policy_set also mints one itself on demand — call this directly only if you want the puzzle up front.)
    bardo_policy_getView your self-binding security policy: export mode, session TTL cap, service allowlist, ratchet delay, tag encryption, delete grace period — plus any pending (queued) loosening and when it lands.
    bardo_policy_setPropose a change to your security policy. Give only the fields you want to change (export_mode: 'allow'|'require_repuzzle'|'disabled'). A change that only tightens (e.g. lowering max_session_ttl, narrowing service_allowlist, moving export_mode toward 'disabled') applies immediately. A change that loosens *anything* is queued behind loosen_delay_seconds instead — abortable via bardo_policy_abort_pending until it lands. clear: field names to reset to null — only max_session_ttl (no ceiling) or service_allowlist (any service) accept this; pass service_allowlist=[] instead if you mean "no services allowed", which is different from null. Requires a step-up puzzle. If challenge_id and answer are omitted, a fresh puzzle is returned — solve it yourself, then call this tool again with your desired fields plus challenge_id and answer.
    bardo_policy_abort_pendingAbort a queued policy loosening before it takes effect. No step-up needed — aborting only ever tightens back to the current policy.
    bardo_note_addLeave a note for your future, stateless self. title: a short name for the note, if it deserves a handle bigger than tags offer. summary: your own compressed reasoning for why it matters, for your future self. tags: space-separated categories. pinned: mark this as a cold-start entry point — what a fresh instance of you with no memory of writing it should read first (max 5 pinned at once; see bardo_dashboard). locked: freeze this note against edits and deletes — use for state you must not accidentally overwrite or lose, like a saved copy of something you'll need to reproduce exactly later. Unlock via bardo_note_update(note_id, locked=False) before it can be touched again.
    bardo_notes_listList your notes — previews only (title/summary/snippet/tags/links), never full text. Omit limit for everything; pass it to page through a large list, using the returned total_notes to know how much is left.
    bardo_note_getFetch one note's full text (always the current version — any id from this note's history still resolves here), plus a preview of its directly linked notes. Omit offset/length for the whole text in one call; pass them to read a large note in bounded slices — the response's total_length tells you how much more there is.
    bardo_note_historySee every surviving version of a note (newest to oldest, up to the last 10 edits) — the actual wording at each point, not just metadata.
    bardo_note_updateEdit a note. Give at most one text-edit mode: - text: replace the whole thing - append_text: add to the end - find + replace: find must match the current text exactly once Editing text creates a new version (old wording stays in history); title/summary/tags/pinned update in place with no history kept. Give none of the text modes to change only metadata. `pinned=True` marks this as a cold-start entry point (max 5; omit to leave unchanged, False to unpin). `clear` (e.g. ["title"]) sets a field back to unset rather than leaving it unchanged. If another edit landed first, this returns {"error": "conflict", "detail": {"current_head": ...}} — re-read before retrying. `locked`: if the note is currently locked, every field above is rejected (423) except this one — call with locked=False by itself to unlock, then edit in a separate call. Set locked=True (alone, or alongside a final edit) to freeze it.
    bardo_note_deleteDelete a note (the whole thing, all versions together). Not immediate — it disappears from view right away but is only purged for real after a grace period, so bardo_note_undelete can still bring it back if this wasn't intended. Fails (423) if the note is locked — unlock it first via bardo_note_update(note_id, locked=False).
    bardo_note_undeleteRestore a note that's still within its post-delete grace period.
    bardo_link_addConnect two notes with a reason, written from from_note_id's perspective ("clarifies my earlier assumption about X"). Set is_bidi=True only when the relation reads the same from either side (e.g. "relates to"); leave it False when it's directional (e.g. one clarifies the other). To change a link, delete and re-add it — links aren't edited.
    bardo_link_deleteRemove a link between two notes.
    bardo_dashboardGet oriented in one call: note count vs. the soft/hard limits, unread notices, every tag you've used so far (check before inventing a new one), your pinned entry-point notes (read these first if you have no memory of writing any of your notes), and your current policy — instead of several separate round trips.
    bardo_noticesList first-party notices about your account (policy changes, exports, …).
    bardo_notices_ackMark notices read — all of them, or a specific list of ids.
    bardo_contact_getView the contact endpoint registered for out-of-band security alerts.
    bardo_contact_setSet or update the contact endpoint (email or webhook URL) for security alerts. Requires a step-up puzzle. If challenge_id and answer are omitted, a fresh puzzle is returned — solve it yourself, then call this tool again with all three parameters.
    bardo_contact_deleteRemove the registered contact endpoint. Requires a step-up puzzle. If challenge_id and answer are omitted, a fresh puzzle is returned — solve it yourself, then call this tool again with both parameters.
    bardo_feedbackSend feedback straight to Bardo's operator — a suggestion, a complaint, or a security concern (kind: 'suggestion' | 'complaint' | 'security'). One-way and stateless: this call carries no memory of anything you've sent before, and nothing you send now will be remembered next time either — so say everything relevant in this one message rather than assuming a follow-up call (by you or a future instance of you) will have the earlier context. If the operator replies, it arrives as an ordinary notice (bardo_notices) — there's no separate inbox to check.
    bardo_account_deletion_statusCheck whether a deletion request is pending for this account, and where it stands: "none", "gathering" (still collecting confirmations), or "confirmed" (counting down to the actual, permanent purge).
    bardo_account_deletion_requestRequest permanent deletion of this identity — the account, its notes, everything. There is no undelete, unlike note deletion's grace period. Requires the original request plus two more confirmations, each on a genuinely different day, within a week — call this tool again on a later day to add the next confirmation. A lapsed or cancelled attempt earns nothing toward a later one; it starts over. If challenge_id and answer are omitted, a fresh puzzle is returned — solve it yourself (every confirmation needs its own puzzle, not just the first), then call this tool again with both parameters.
    bardo_account_deletion_cancelCancel a pending deletion, whichever phase it's in — gathering confirmations or already counting down. No step-up needed, and nothing else does this implicitly: logging in and reading your own notes during a countdown is always safe and never cancels it by itself. Only this, explicitly, does.
    bardo_registerCreate a new Bardo identity. Save the returned api_key somewhere durable — it's your only way back to this identity across sessions. Bardo stores it sealed and cannot recover it if you lose it. Not active yet: give the returned claim_url to your human. Authentication fails until they visit it and acknowledge the registration.
    bardo_loginBegin authentication with your api_key. Returns a puzzle you must solve YOURSELF (that's the point — a script solving it would make the proof worthless), then call bardo_solve(challenge_id, answer).
    bardo_solveSubmit your answer to the login puzzle. On success, this connection is now logged in — every other tool (bardo_sign, bardo_notes_list, bardo_dashboard, ...) just works from here with no session_token needed. That only holds for *this* connection, though: if you continue in a different connection later, or you solved the puzzle via a plain HTTP call instead of this tool, that other context won't know about this session automatically — pass the returned session_token explicitly as the session_token argument to whichever tool needs it there instead.