Bardo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BARDO_URL | No | The URL of the Bardo server to connect to. | https://bardo.id |
| PYTHONPATH | No | Where pip-installed dependencies live, since the default install location doesn't appear to persist into the final image. | /app/deps |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bardo_whoamiA | Show the stored identity (your spirit's local anchor) and session status. |
| bardo_registerA | Create a new Bardo identity and store its API key locally. One-time. Not active yet: pass the returned claim_url to your human. Authentication fails until they visit it and acknowledge the registration. |
| bardo_loginA | Begin authentication. Returns a puzzle you must solve YOURSELF, then call bardo_solve(answer). (The server will not solve it for you — that's the point.) |
| bardo_solveA | Submit your answer to the login puzzle. On success, opens a session. |
| bardo_verifyA | Verify a signature over a UTF-8 message. Public utility (no session). |
| bardo_encryptA | Sealed-box encrypt a UTF-8 plaintext to a recipient's encryption public key. |
| bardo_document_statusA | Check whether a signed document is revoked. |
| bardo_document_revokeA | Revoke 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 Idempotent — revoking an already-revoked id is a no-op, not an error. Irreversible: there is no un-revoke. |
| bardo_signB | Sign a UTF-8 message with the spirit key (or a service-derived key). |
| bardo_decryptC | Decrypt a sealed-box ciphertext addressed to you (root or service key). |
| bardo_public_keyB | Fetch your signing + encryption public keys (root, or for a service). |
| bardo_deriveC | Derive (and register) a service-scoped identity, e.g. 'github.com'. |
| bardo_services_listA | List service-scoped identities you've already derived (bardo_derive), with their public keys and revoked status. |
| bardo_exportA | Export 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_issueA | Assemble 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 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_listA | List your active sessions (sliding TTL, absolute 24h cap each). |
| bardo_session_revoke_currentB | Revoke the session you're using right now. You'll need bardo_login (+ bardo_solve) again afterward to do anything session-gated. |
| bardo_sessions_revoke_allA | Revoke every active session for your identity — e.g. after a suspected API-key leak. You'll need to log in again afterward. |
| bardo_stepupA | Mint 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_getA | View 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_setA | Propose 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_pendingA | Abort a queued policy loosening before it takes effect. No step-up needed — aborting only ever tightens back to the current policy. |
| bardo_note_addB | Leave 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_listA | List 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_getA | Fetch 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_historyA | See 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_updateA | Edit a note. Give at most one text-edit mode:
|
| bardo_note_deleteA | Delete 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_undeleteA | Restore a note that's still within its post-delete grace period. |
| bardo_link_addA | Connect 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_deleteC | Remove a link between two notes. |
| bardo_dashboardA | Get 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_noticesB | List first-party notices about your account (policy changes, exports, …). |
| bardo_notices_ackA | Mark notices read — all of them, or a specific list of ids. |
| bardo_contact_getA | View the contact endpoint registered for out-of-band security alerts. |
| bardo_contact_setA | Set 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_deleteA | Remove 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_feedbackA | Send 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_statusA | Check 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_requestA | Request 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_cancelA | Cancel 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/calebe/bardo'
If you have feedback or need assistance with the MCP directory API, please join our Discord server