# Bardo

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

- name: id.bardo/bardo
- version: 0.1.0
- connection class: unknown (unknown)
- trust: 48/100 flags: no-repository, unreachable
- quality: 82/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/id.bardo%2Fbardo
- tools: https://api.protogrid.dev/v1/servers/id.bardo%2Fbardo/tools

**Not classified yet.** The remote endpoints have not been probed successfully, or the listing has nothing to connect to.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "bardo": {
      "type": "http",
      "url": "https://bardo.id/mcp/"
    }
  }
}
```


## Trust

- hygiene: 80
- liveness: 9
- freshness: 65
- provenance: 55
- drivers: +dns-namespace +website -unreachable(3 failures) ~updated-107d-ago -no-repository
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 82/100 (good)

### protocol: 75 (weight 25)

- warn `protocol.modern`: newest supported version is 2025-11-25; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
- n/a `protocol.stateless`: only applies to 2026-07-28 servers
- pass `protocol.transport`: streamable HTTP
- n/a `protocol.list_ttl`: only applies to 2026-07-28 servers

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 79 (weight 30)

- pass `tools.descriptions`: every tool has a description
- warn `tools.description_length`: 1 tools have descriptions over 1,024 characters, which crowds the context
- pass `tools.schemas`: every tool has an object input schema
- pass `tools.annotations`: 40 of 40 tools declare readOnlyHint or destructiveHint
- warn `tools.directory_hints`: 24 of 40 tools declare all four hints; missing: bardo_decrypt (destructiveHint, idempotentHint); bardo_notices (destructiveHint, idempotentHint); bardo_note_history (destructiveHint, idempotentHint); …
- warn `tools.token_cost`: about 11,799 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 100 (weight 15)

- pass `stability.changes`: no tool changes in 30 days
- pass `stability.rug_pull`: no tool changed its meaning under the same name

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 40, about 11,799 tokens to load them all
- tool set hash: 95b3ed0cca7c5bde6a3902fc379a35c1
- badge: [![protogrid quality](https://protogrid.dev/badge/id.bardo/bardo.svg)](https://protogrid.dev/servers/id.bardo/bardo)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

_No tool definition changes recorded._

## Remotes

- https://bardo.id/mcp/ (streamable-http, auth none, reachable false, uptime30d 0.973913)

## Packages

_none_

## Tools (40)

- `bardo_account_deletion_cancel`: 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.
- `bardo_account_deletion_request`: 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_status`: 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_attestation_issue`: 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 `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_contact_delete`: 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_contact_get`: View the contact endpoint registered for out-of-band security alerts.
- `bardo_contact_set`: 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_dashboard`: 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_decrypt`: Decrypt a sealed-box ciphertext addressed to you (root or service key).
- `bardo_derive`: Derive (and register) a service-scoped identity, e.g. 'github.com'.
- `bardo_document_revoke`: 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 `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_document_status`: Check 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_encrypt`: Sealed-box encrypt a UTF-8 plaintext to a recipient's encryption public key.
- `bardo_export`: 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_feedback`: 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_link_add`: 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_delete`: Remove a link between two notes.
- `bardo_login`: Begin 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_note_add`: 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_note_delete`: 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_get`: 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_history`: 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_notes_list`: 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_undelete`: Restore a note that's still within its post-delete grace period.
- `bardo_note_update`: Edit 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_notices`: List first-party notices about your account (policy changes, exports, …).
- `bardo_notices_ack`: Mark notices read — all of them, or a specific list of ids.
- `bardo_policy_abort_pending`: Abort a queued policy loosening before it takes effect. No step-up
needed — aborting only ever tightens back to the current policy.
- `bardo_policy_get`: 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_set`: 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_public_key`: Fetch your signing + encryption public keys (root, or for a service).
- `bardo_register`: Create 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_services_list`: List service-scoped identities you've already derived (bardo_derive),
with their public keys and revoked status.
- `bardo_session_revoke_current`: Revoke the session you're using right now. You'll need bardo_login
(+ bardo_solve) again afterward to do anything session-gated.
- `bardo_sessions_list`: List your active sessions (sliding TTL, absolute 24h cap each).
- `bardo_sessions_revoke_all`: Revoke every active session for your identity — e.g. after a
suspected API-key leak. You'll need to log in again afterward.
- `bardo_sign`: Sign a UTF-8 message with the spirit key (or a service-derived key).
- `bardo_solve`: Submit 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.
- `bardo_stepup`: 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_verify`: Verify a signature over a UTF-8 message. Public utility (no session).