Skip to main content
Glama
Protocol Chaos reference server

Protocol Chaos reference server

by chaos-xxl

npm Specification Tests License

English · 简体中文

An open protocol for the matters in a person's life, held by the person and shared by every AI assistant they use.

People tell their AI assistants about trips, renovations, job searches, purchases and ambitions. Each assistant keeps what it hears to itself, so the same plan is explained again to every new assistant and is lost when the tool changes. Protocol Chaos keeps these matters in one repository that belongs to the user. Any compatible assistant can read it, add to it and connect what it holds, and the matters outlast any one assistant.

With Protocol Chaos, an assistant can:

  • Pick up where another left off: read what the user told a different assistant, on a different computer, weeks ago.

  • Keep the user's words: record them verbatim, and mark its own inferences as inferences.

  • Connect matters: place a trip under the wish it serves, and point it at the people it involves.

  • Write alongside other assistants: without overwriting what another has committed, with every change recorded.

flowchart LR
  claude[Claude] <--> server
  codex[Codex] <--> server
  cursor[Cursor] <--> server
  app[Your own app] <--> server
  server["A Protocol Chaos server<br/>any conforming implementation"] --- repo[("The user's repository<br/>Events · words · Entities · history")]

Quick start

You need Node.js 20 or later and an assistant that can use MCP servers. Add the reference server under the name protocol_chaos:

  • Claude Code:

    claude mcp add --scope user protocol_chaos -- npx -y protocol-chaos@0.2
  • Codex, in ~/.codex/config.toml:

    [mcp_servers.protocol_chaos]
    command = "npx"
    args = ["-y", "protocol-chaos@0.2"]
  • Claude Desktop, Cursor, Kiro and other clients configured in JSON (claude_desktop_config.json, ~/.cursor/mcp.json, ~/.kiro/settings/mcp.json):

    { "mcpServers": { "protocol_chaos": { "command": "npx", "args": ["-y", "protocol-chaos@0.2"] } } }

Then tell one assistant about something you are planning, for example "I'd like to get into street photography, but only at weekends". Ask another assistant, or a new conversation, what you said about photography. The matter is stored in ~/.protocol-chaos/repository.json, a plain file that belongs to you.

For assistants on several computers, or a cloud assistant, run the same server over HTTP and give each assistant its own token: see Remote.

For the best results, give each assistant the standing instructions: MCP tells an assistant which tools exist, not when to use them. protocol-chaos@0.2 follows this draft and its fixes; a later draft will be 0.3.

Related MCP server: datacore-mcp

Why Protocol Chaos?

  • The user holds the matters. The repository belongs to the user, not to an assistant or a vendor, and every conforming server can export it whole and import it elsewhere.

  • Matters are connected. What looks like a one-off rarely is: a trip belongs to a wish to see more of the world, a camera serves a hobby. Parents, and the people and places Events share, make those connections explicit.

  • Words are evidence. The user's words are kept verbatim and never edited. Everything an assistant concludes rests on them, and the user's words win.

  • Sparse is normal. A matter can be one sentence. Assistants record what was said instead of questioning the user to complete it.

  • Small and testable. The specification defines only what implementations must agree on, and every requirement on servers has a conformance test.

  • Built on MCP. Every operation is an MCP tool, so any MCP client can use a conforming server, written in any language.

What the protocol defines

Events

A matter: its title, state and progress; its goal, constraint and plan, in natural language; the people, places and things it involves; and the larger Events it is part of.

Accounts

The user's words an Event rests on, kept verbatim and never edited.

Entities

The people, animals, things and places the user refers to, the user included, each described by one-fact Statements.

Revisions

Every change, naming who made it and the words it rests on.

Writer rules

What to record and what not to, so that every assistant writing to the same repository behaves the same way.

Levels

Core, and the optional levels Entities, Search, Sync, Undo and Remote.

How a client finds the Events a conversation is about, how it ranks them and when it tidies up are left to the client. The full rules are in PROTOCOL.md.

Repository contents

Path

PROTOCOL.md

The specification. Normative.

conformance/

Conformance tests that check any server over MCP.

server/

The reference server, at every level from Core to Remote: over stdio on one computer, or over HTTP for several.

docs/agent-guide.md

How an assistant can use a repository well: answer first, record after, organise later. Not normative.

integrations/hermes/

A plugin for Hermes Agent: the user's matters are in the conversation before the model answers, and their words are recorded after it. Hermes decides on its own side what to read.

Implementing the protocol

  1. Read PROTOCOL.md and start with the Core level (§12).

  2. Offer the operations as MCP tools (§9.1): over stdio on one computer, or over streamable HTTP, with a credential for each client, when several computers share a repository (§9.2).

  3. Test your server, whatever its language, with no need to clone anything:

    npx -y -p protocol-chaos@0.2 protocol-chaos-conformance --stdio "node my-server.js --data {tmp}"

    {tmp} becomes a fresh, empty directory for each server the suite starts. The tests write data, so they refuse to run against a repository that is not empty.

The specification is meant to be enough on its own. To check that, an agent that had never seen any implementation wrote a server from the document alone. Its first run passed 39 of the 40 Core tests of the time, and the one gap it found was fixed in the document. That server became the reference server here.

Your data

  • The repository belongs to its user, and can always be exported and moved to another server (§8.6).

  • The reference server keeps it in one file on the computer it runs on and sends it nowhere. Over HTTP it answers only assistants that hold a token you issued.

  • Every connected assistant can currently read the whole repository; per-client visibility is not designed yet (§13). Connect only assistants you would trust with all of it. What an assistant reads enters its model context and is processed by its provider.

  • Assistants are told never to record passwords, tokens or identity-document numbers (§7).

Status and roadmap

Protocol Chaos is a draft, and drafts carry no compatibility promise. Draft 0.2 grew out of daily use: its author has used an implementation of draft 0.1 every day, with several assistants on different computers sharing one repository, and draft 0.2 keeps what that use showed to matter. That implementation is not part of this repository, and is moving to draft 0.2.

Next:

  • The Hermes plugin in Hermes's plugin catalog, once it has been in daily use for a while.

  • Per-client visibility: what each assistant may read (§13).

  • Recognising the same person across applications (§13).

  • Draft 0.3, from the cases people report.

The changelog lists every release.

FAQ

Is this a memory product? No, it is a protocol: an agreement on how a person's matters are kept, so that any assistant can use them. An assistant's own memory stays with that assistant; Protocol Chaos keeps the matters for the person, across assistants.

Do I need a server? Yes, any conforming one. The reference server runs on your computer with one command. You can also write your own, and the conformance tests tell you when it is right.

Which assistants work with it? Any MCP client. The quick start covers Claude Code, Codex, Claude Desktop, Cursor and Kiro on one computer. Over HTTP, the Remote level, assistants on other computers and cloud assistants that can reach your server share the same repository.

Where is my data? Where your server runs, and nowhere else. See Your data.

Contributing

What the protocol needs most is evidence from real use: cases where it fits, cases where it falls short, and implementations.

See CONTRIBUTING.md for how changes are decided.

About

Protocol Chaos was created by Xue Xinglong (@chaos-xxl), and is part of the Chaos family, alongside Doctor Chaos. It is licensed under the Apache License 2.0.

Available Tools

14 tools
context_packA
Read-only

The directory: every Event in brief, {id, title?, state, parents, progress?, updatedAt}, most recently updated first, from which you decide what to read. Pass sinceVersion (the version you cached) to learn whether anything changed; filter by state (a state, "open" or "closed"); page with limit and cursor (pass next).

Inputs: limit, state, cursor, sinceVersion.

entity_createA

Create an Entity: one specific person, animal, thing or place that recurs across Events or applications and has user-specific information to accumulate (otherwise use a {criteria} ref on the Event). Search first (entity_search). accountText holds the words it rests on; statements are its first facts, one fact each, 1 to 200 characters, with absolute dates. owner: true only for the user's own Entity (at most one). Verbatim rule: the words (text, accountText) are the user's actual words, trimmed and otherwise unchanged, never a summary or a third-person paraphrase; pass the part about this Entity. Statements are your one-fact interpretation; mark an inference with basis. Returns {entityId, version, accountId, added}.

Inputs: kind (required), name (required), actor (required), accountText (required), +5 more.

entity_getA
Read-only

Read one Entity. entityId is an Entity id or "current_user" (the user's own Entity). view "summary" returns {entity, summary}: the short list of Statements meant to be loaded into every conversation (never sensitive ones). view "full" (default) returns {entity, statements}: the Statements that are not outdated, by topic, then by creation. includeHistory adds history (the outdated ones); includeEvents adds referencedBy (the Events whose refs name it); topics restricts the Statements returned.

Inputs: entityId (required), view, topics, includeEvents, +1 more.

entity_recordA

Record words about an Entity together with what they change: name, aliases (the complete new list), add (new Statements; may supersede or conflict with existing ones), update (status, reason, sensitivity, inSummary of existing Statements) and support (existing Statements these words also support). Saying the same thing again is merged into the existing Statement as more evidence. A Statement resting on the user's words can be superseded, or its status changed, only by the user's own words (USER_WORDS_PROTECTED): add your version with conflictsWith instead. A disputed Statement becomes current again only by the user's words (USER_CONFIRMATION_REQUIRED). Carry expectedVersion (the Entity's). Verbatim rule: the words (text, accountText) are the user's actual words, trimmed and otherwise unchanged, never a summary or a third-person paraphrase; pass the part about this Entity. Statements are your one-fact interpretation; mark an inference with basis. Returns {entityId, version, accountId, added?, merged?, changed?, supported?}.

Inputs: text (required), actor (required), entityId (required), add, +7 more.

event_add_parentA

Link an Event (child) as part of a larger Event (parent). Link only when it is plainly part of it or a step toward it; two separate trips are siblings. Ground the link on Accounts of the child or of the parent. Adding an existing link changes nothing; a link that would close a cycle fails with PART_OF_CYCLE. Returns {eventId, version, parents} for the child.

Inputs: actor (required), childEventId (required), parentEventId (required), sourceAccountIds (required), +1 more.

event_get_protocolA
Read-only

Read one Event: {event, accounts, entities?}, the document, its most recent Accounts (default 20, or "all"), oldest first, and, when its refs name Entities, those Entities as {id, kind, name}. History is read with event_get_revisions.

Inputs: eventId (required), accounts.

event_get_revisionsA
Read-only

Read the history of an Event: its Revisions in commit order. Page with limit and after (pass next).

Inputs: eventId (required), after, limit.

event_noteA

Record the user's words on an Event, or start a new Event with them. Changes nothing else (it gives a title only to an Event that has none). With eventId the words are appended; without it a new Event starts in state emerging, optionally titled and placed under parentEventId. Check the directory first so one matter does not become two. Verbatim rule: text is the user's actual words, trimmed and otherwise unchanged, never a summary or a third-person paraphrase such as "The user confirmed…"; when a message covers several Events, pass the part about this Event, still in the user's words. Interpretation belongs in the fields. Returns a receipt.

Inputs: text (required), actor (required), via, title, +3 more.

event_record_expressionA

Record words together with the changes they support, atomically: set any of title, state, progress, facts (goal, constraint, plan), refs and metadata. To fold words recorded earlier into fields, pass that Account's accountId and its exact text instead of appending new words. Each supplied field replaces the stored one, so supply its complete current content and carry over what still holds; null removes a field. Mark your own inferences inside the fact text with their basis. Verbatim rule: text is the user's actual words, trimmed and otherwise unchanged, never a summary or a third-person paraphrase such as "The user confirmed…"; when a message covers several Events, pass the part about this Event, still in the user's words. Interpretation belongs in the fields. Returns a receipt.

Inputs: text (required), actor (required), eventId (required), set, +4 more.

event_remove_parentA
Destructive

Remove the link "child is part of parent", grounded on Accounts of the child or of the parent. Removing a link that does not exist fails with NOT_FOUND. Returns {eventId, version, parents} for the child.

Inputs: actor (required), childEventId (required), parentEventId (required), sourceAccountIds (required), +1 more.

event_undo_revisionA
Destructive

Undo the latest change of an Event that has not been undone: a field.changed, parent.added or parent.removed Revision (words recorded since do not count). Events and words are never removed, so event.created and account.added cannot be undone, nor can an undo. Anything else fails with REVISION_NOT_REVERSIBLE, for example after another writer changed the Event: read it again and reconsider. Records a revision.reverted Revision and returns it; call again on the next change to walk further back.

Inputs: actor (required), revisionId (required).

event_words_sinceA
Read-only

The words recorded since a moment, for folding them into fields later or refreshing a cache. Returns {version, checkpoint, remaining, events}: each Event that gained Accounts after since, with its current title, state, facts, refs, progress and parents, and words, its new Accounts, oldest first. Pass checkpoint as the next since to continue; remaining counts the Accounts not yet returned. limit is the number of Events per batch (a batch never ends between two Accounts with the same createdAt). Going over the same words twice changes nothing, because each field write carries the complete current content.

Inputs: since (required), limit.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.9/5.0

    Scored across 14 tools

    Disambiguation4/5

    Most tools target a distinct resource+action (search vs get vs revisions, entity vs event, add vs remove parent). The one real overlap is event_note vs event_record_expression, both of which record the user's words, though descriptions clarify that one is words-only and the other bundles field changes.

    Naming Consistency3/5

    There is a clear event_*/entity_* namespacing pattern, which is good. But the verb style drifts: event_get_protocol, event_words_since, and context_pack break the predictable prefix_verb_noun convention used elsewhere (e.g. entity_get, event_search).

    Tool Count4/5

    Fourteen tools for an event/entity recording protocol is well-scoped, with each tool covering a coherent capability. It sits at the upper end but nothing feels redundant or padded.

    Completeness4/5

    The surface covers the full lifecycle: capture words, mutate fields, link/unlink events, read protocol and history, search, sync deltas, and undo. Entity side covers search/get/create/record. Deletion and event-creation are intentionally folded into other tools, leaving only minor gaps (e.g. no dedicated entity history/undo path).

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP server for AI agents to read, write, and organize notes in a local-first, human-in-the-loop note-taking app.
      9 npm
      2
      MIT
    • F
      license
      Not graded
      quality
      C
      maintenance
      A remote MCP server that gives AI assistants a shared memory, enabling structured handoffs, journaling, and notes for seamless continuation across sessions.
      -
    • A
      license
      A
      quality
      B
      maintenance
      Persistent memory server for MCP clients that lets AI assistants remember facts about users across sessions via a single markdown file, with tools to read, save, search, update, delete, and organize memory.
      10
      MIT