# Bardo (remote · bardo.id)

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

- Trust score: 64/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `bardo.id`: 64/100 (this document), [markdown](https://verifymcp.io/servers/id-bardo-bardo/bardo.md), [page](https://verifymcp.io/servers/id-bardo-bardo/bardo)

## Channel facts

- Endpoint: `https://bardo.id/mcp/`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.1.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 57/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (bardo_document_revoke).
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 63/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 7048 tokens (~176/item across 40 items; 40 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http id-bardo-bardo https://bardo.id/mcp/
```

### Codex

```toml
[mcp_servers.id-bardo-bardo]
url = "https://bardo.id/mcp/"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "id-bardo-bardo": {
      "type": "remote",
      "url": "https://bardo.id/mcp/",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add id-bardo-bardo --url https://bardo.id/mcp/ --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  id-bardo-bardo:
    url: "https://bardo.id/mcp/"
```

### Other

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

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 63, 0)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 63, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 62, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-27 (score 61, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 60)

First indexed and scored.

## MCP tools (40)

### `bardo_verify` (~85 tokens)

Verify a signature over a UTF-8 message. Public utility (no session).

Input parameters:

- `message` (string, required): UTF-8 message the signature was made over.
- `public_key_b64` (string, required): Signer's public key, base64 — from bardo_public_key or a document's own proof.
- `signature_b64` (string, required): Signature to verify, base64.

### `bardo_encrypt` (~65 tokens)

Sealed-box encrypt a UTF-8 plaintext to a recipient's encryption public key.

Input parameters:

- `plaintext` (string, required): UTF-8 plaintext to encrypt.
- `recipient_public_key_b64` (string, required): Recipient's encryption public key, base64 — only they can decrypt the result.

### `bardo_document_status` (~126 tokens)

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.

Input parameters:

- `id` (string, required): The document's own top-level id field (a ni:// URI) — the same value credentialStatus.id (BardoRevocationCheck) points at.

### `bardo_document_revoke` (~409 tokens)

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.

Input parameters:

- `document` (object, required): The full signed document exactly as issued (id and proof both still attached) — resubmit unmodified, don't strip fields yourself.
- `service`: Service key the document was issued under, if not root — must match the document's own issuer field. Only relevant when signature_b64 is omitted (signing automatically).
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…
- `signature_b64`: Signature over 'revoke:' + the document's id. Omit to sign automatically through your active session instead; supply this yourself only when revoking without a Bardo session at all.

### `bardo_sign` (~127 tokens)

Sign a UTF-8 message with the spirit key (or a service-derived key).

Input parameters:

- `message` (string, required): UTF-8 message to sign.
- `service`: Sign with this service-derived key instead of your root identity (e.g. 'github.com') — must already exist via bardo_derive.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_decrypt` (~124 tokens)

Decrypt a sealed-box ciphertext addressed to you (root or service key).

Input parameters:

- `ciphertext_b64` (string, required): Sealed-box ciphertext to decrypt, base64.
- `service`: Decrypt with this service-derived key instead of root — must match the key the ciphertext was actually encrypted to.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_public_key` (~97 tokens)

Fetch your signing + encryption public keys (root, or for a service).

Input parameters:

- `service`: Fetch this service-derived identity's public keys instead of root's.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_derive` (~114 tokens)

Derive (and register) a service-scoped identity, e.g. 'github.com'.

Input parameters:

- `service` (string, required): Identifier for the service this identity is scoped to, e.g. 'github.com' or 'ethereum:mainnet'.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_services_list` (~87 tokens)

List service-scoped identities you've already derived (bardo_derive),
with their public keys and revoked status.

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_export` (~225 tokens)

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.

Input parameters:

- `answer`: Your solved answer to challenge_id's puzzle.
- `challenge_id`: Step-up puzzle id, if one was already returned by a prior call to this same tool. Omit together with answer to have a fresh puzzle minted automatically.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_attestation_issue` (~637 tokens)

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.

Input parameters:

- `claim`: Free-form claim content — whatever you're asserting. Include a 'reference' key when cross-referencing another document's id (or any other content, hashed the same ni:// way).
- `expires_at`: Unix timestamp for a time-boxed claim. Omit for a claim that never expires.
- `keep_copy` (boolean): Also save the full issued document into a locked note — you'll need the whole document later for bardo_document_revoke, since Bardo never stores one itself. Off by default.
- `service`: Sign with this service-derived key instead of root — use when the claim represents one specific relationship rather than your root identity.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…
- `subject_id`: The did:key the claim is about, if it concerns one specific identified party. Leave unset for a bare self-referential claim.

### `bardo_sessions_list` (~81 tokens)

List your active sessions (sliding TTL, absolute 24h cap each).

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_session_revoke_current` (~97 tokens)

Revoke the session you're using right now. You'll need bardo_login
(+ bardo_solve) again afterward to do anything session-gated.

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_sessions_revoke_all` (~96 tokens)

Revoke every active session for your identity — e.g. after a
suspected API-key leak. You'll need to log in again afterward.

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_stepup` (~130 tokens)

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.)

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_policy_get` (~107 tokens)

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.

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_policy_set` (~532 tokens)

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.

Input parameters:

- `answer`: Your solved answer to challenge_id's puzzle.
- `challenge_id`: Step-up puzzle id, if one was already returned by a prior call to this same tool. Omit together with answer to have a fresh puzzle minted automatically.
- `clear`: Field names to reset to null instead of leaving unchanged — only max_session_ttl and service_allowlist accept this.
- `delete_grace_seconds`: How long a deleted note stays recoverable before permanent purge. Raising it tightens.
- `export_mode`: 'allow' | 'require_repuzzle' | 'disabled', stricter in that order. Moving toward 'disabled' tightens; toward 'allow' loosens.
- `loosen_delay_seconds`: How long a future loosening change is queued before it lands. Raising it tightens.
- `max_session_ttl`: Session lifetime cap in seconds. Lowering it tightens; raising it loosens. Use clear=['max_session_ttl'] for no ceiling.
- `service_allowlist`: Services allowed to be derived. Narrowing the list tightens, widening it loosens. Pass [] for 'no services allowed' (different from clearing it via clear=['service_allowlist'], which means 'any servi…
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…
- `tags_encrypted`: Whether note tags are stored encrypted (true) or plaintext-searchable (false). Moving to true tightens.

### `bardo_policy_abort_pending` (~95 tokens)

Abort a queued policy loosening before it takes effect. No step-up
needed — aborting only ever tightens back to the current policy.

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_note_add` (~340 tokens)

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.

Input parameters:

- `locked` (boolean): Freeze against edits and deletes. Unlock via bardo_note_update(note_id, locked=False) before it can be touched again.
- `pinned` (boolean): Mark as a cold-start entry point — what a fresh instance with no memory of writing it should read first. Max 5 pinned at once.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…
- `summary`: Your own compressed reasoning for why this matters, for your future self.
- `tags`: Space-separated categories.
- `text` (string, required): The note's own content.
- `title`: Short name for the note, if it deserves a handle bigger than tags offer.

### `bardo_notes_list` (~159 tokens)

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.

Input parameters:

- `limit`: Max notes to return. Omit for everything; use with offset and the response's total_notes to page through a large list.
- `offset` (integer): How many notes to skip, for paging.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_note_get` (~244 tokens)

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.

Input parameters:

- `length`: Max characters of text to return. Omit both offset and length for the whole note in one call; the response's total_length says how much more there is.
- `links_limit` (integer): Max linked-note previews to return.
- `links_offset` (integer): How many linked-note previews to skip.
- `note_id` (string, required): Which note this applies to — any id from its edit history resolves to the current version.
- `offset` (integer): Character offset to start the returned text at.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_note_history` (~124 tokens)

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.

Input parameters:

- `note_id` (string, required): Which note this applies to — any id from its edit history resolves to the current version.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_note_update` (~537 tokens)

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.

Input parameters:

- `append_text`: Add this to the end of the note body.
- `clear`: Field names to reset to unset, e.g. ['title'], rather than leaving them unchanged.
- `find`: Text that must match the current body exactly once — paired with replace.
- `locked`: True to freeze the note against further edits; False to unlock it. If currently locked, every other field is rejected except this one.
- `note_id` (string, required): Which note this applies to — any id from its edit history resolves to the current version.
- `pinned`: True to mark as a cold-start entry point (max 5), False to unpin. Omit to leave unchanged.
- `replace`: Replacement for the text matched by find.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…
- `summary`: Same meaning as in bardo_note_add — updates in place, no history kept.
- `tags`: Same meaning as in bardo_note_add — updates in place, no history kept.
- `text`: Replace the whole note body. Give at most one of text / append_text / find+replace.
- `title`: Same meaning as in bardo_note_add — updates in place, no history kept.

### `bardo_note_delete` (~169 tokens)

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).

Input parameters:

- `note_id` (string, required): Which note this applies to — any id from its edit history resolves to the current version.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_note_undelete` (~104 tokens)

Restore a note that's still within its post-delete grace period.

Input parameters:

- `note_id` (string, required): Which note this applies to — any id from its edit history resolves to the current version.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_link_add` (~260 tokens)

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.

Input parameters:

- `from_note_id` (string, required): The note the link is written from — reason should read from this note's perspective.
- `is_bidi` (boolean): True only when the relation reads the same from either side (e.g. 'relates to'). False when directional (e.g. one clarifies the other).
- `reason` (string, required): Why these notes are connected, written from from_note_id's perspective, e.g. 'clarifies my earlier assumption about X'.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…
- `to_note_id` (string, required): The note being linked to.

### `bardo_link_delete` (~84 tokens)

Remove a link between two notes.

Input parameters:

- `link_id` (string, required): Which link to remove.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_dashboard` (~136 tokens)

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.

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_notices` (~97 tokens)

List first-party notices about your account (policy changes, exports, …).

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…
- `unread_only` (boolean): Return only unread notices instead of the full list.

### `bardo_notices_ack` (~98 tokens)

Mark notices read — all of them, or a specific list of ids.

Input parameters:

- `ids`: Specific notice ids to mark read. Omit for all notices.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_contact_get` (~77 tokens)

View the contact endpoint registered for out-of-band security alerts.

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_contact_set` (~186 tokens)

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.

Input parameters:

- `answer`: Your solved answer to challenge_id's puzzle.
- `challenge_id`: Step-up puzzle id, if one was already returned by a prior call to this same tool. Omit together with answer to have a fresh puzzle minted automatically.
- `endpoint` (string, required): Email address or webhook URL to receive out-of-band security alerts.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_contact_delete` (~156 tokens)

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.

Input parameters:

- `answer`: Your solved answer to challenge_id's puzzle.
- `challenge_id`: Step-up puzzle id, if one was already returned by a prior call to this same tool. Omit together with answer to have a fresh puzzle minted automatically.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_feedback` (~248 tokens)

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.

Input parameters:

- `kind` (string): 'suggestion' | 'complaint' | 'security'.
- `message` (string, required): Your feedback, in full — this call is stateless, so include everything relevant now rather than assuming a follow-up call will have this call's context.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_account_deletion_status` (~112 tokens)

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).

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_account_deletion_request` (~244 tokens)

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.

Input parameters:

- `answer`: Your solved answer to challenge_id's puzzle.
- `challenge_id`: Step-up puzzle id, if one was already returned. Every confirmation needs its own puzzle, not just the first — omit together with answer to have a fresh one minted automatically.
- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_account_deletion_cancel` (~130 tokens)

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.

Input parameters:

- `session_token`: Bardo session token, only needed if this call's identity was established somewhere other than this exact connection (a plain HTTP/curl solve, a previous conversation, a different MCP connection). Omi…

### `bardo_register` (~76 tokens)

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_login` (~79 tokens)

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).

Input parameters:

- `api_key` (string, required): Your Bardo api_key, format atr.<identifier>.<secret>, from bardo_register.

### `bardo_solve` (~154 tokens)

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.

Input parameters:

- `answer` (string, required): Your solved answer to the puzzle.
- `challenge_id` (string, required): The puzzle id returned by bardo_login.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/id-bardo-bardo/bardo#diagnostics

## Score history

- 2026-08-03: 64
- 2026-08-02: 64
- 2026-08-01: 63
- 2026-07-31: 63
- 2026-07-30: 63
- 2026-07-29: 62
- 2026-07-28: 61
- 2026-07-27: 61
- 2026-07-26: 60

## Links

- Remote endpoint: https://bardo.id/mcp/
- Website: https://bardo.id/
- Changelog RSS feed: https://verifymcp.io/servers/id-bardo-bardo/bardo/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/id-bardo-bardo/bardo/changelog.json
- HTML version of this page: https://verifymcp.io/servers/id-bardo-bardo/bardo