Protocol Chaos reference server
A reference MCP server for the Protocol Chaos protocol: it lets an assistant record the user's own words, read and search their "matters" (Events) and the people, places and things (Entities) those matters involve, and revise them with history and undo.
Record words —
event_noteappends the user's verbatim words to an Event, or starts a new Event (emerging, optionally titled and placed under a parent Event).Record words with changes —
event_record_expressionatomically records words plus field updates: title, state (emerging/active/waiting/dormant/done/cancelled), progress, facts (goal, constraint, plan), refs and metadata; can also ground changes on an earlier Account.Read one Event —
event_get_protocolreturns the Event, its most recent Accounts (or all) and the Entities its refs name.Browse the directory —
context_packlists every Event in brief, newest first, with state filters, pagination and asinceVersionchange check.Search Events —
event_searchfinds Events by title, facts, progress, refs or recorded words, best matches first.Track words over time —
event_words_sincereturns new Accounts since a checkpoint (paged, with aremainingcount) for folding into fields or refreshing a cache.Read history —
event_get_revisionspages through an Event's Revisions in commit order.Undo —
event_undo_revisionreverses the latest reversible change (field change or parent link), recording arevision.revertedRevision; Events and words are never removed.Connect Events —
event_add_parent/event_remove_parentlink a child Event under a larger parent Event, grounded on Accounts, with cycle detection.Find Entities —
entity_searchlooks up people, animals, things and places by name, alias or Statement text; omit the query to list all.Read an Entity —
entity_getreturns its Statements, a summary view, history, referenced Events and topic filters;"current_user"reads the owner.Create an Entity —
entity_createadds an Entity with aliases, first one-fact Statements (sensitivity, validity dates, summary flags) and the words it rests on.Update an Entity —
entity_recordrecords words with changes: name, aliases, new Statements (with supersede/conflict), status/reason/sensitivity/summary updates, and extra support for existing Statements.Guardrails — every write names the writer (
actor), keeps words verbatim, distinguishes user words from agent inferences (accountSource,basis), and usesexpectedVersionfor optimistic concurrency.
Provides a Hermes Agent plugin that brings the user's Protocol Chaos matters into the conversation before the model answers and records the user's words afterward, allowing Hermes Agent to read from and contribute to the shared repository.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Protocol Chaos reference server what did I say about street photography?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.2Codex, 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 | |
The specification. Normative. | |
Conformance tests that check any server over MCP. | |
The reference server, at every level from Core to Remote: over stdio on one computer, or over HTTP for several. | |
How an assistant can use a repository well: answer first, record after, organise later. Not normative. | |
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
Read PROTOCOL.md and start with the Core level (§12).
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).
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.
Questions and ideas: Discussions
Changes to the specification: a proposal that starts from a real case
Bugs: issues
Security problems: privately, as SECURITY.md describes
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 toolscontext_packARead-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_getARead-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.
entity_searchARead-only
Find the people, animals, things and places the user refers to (Entities), for example before creating one, so that one does not become two. Every Entity whose name or an alias equals the query (ignoring case) comes first, then names and aliases that start with or contain it, then Entities whose Statements contain it. Omit query to list every Entity; filter by kind. Returns {entities}: cards {id, kind, name, aliases?, owner?, version, statements}, where statements counts the Statements that are not outdated.
Inputs: kind, limit, query.
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_protocolARead-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_revisionsARead-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_parentADestructive
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_searchARead-only
Find Events for a query you chose, such as the name of a matter, before creating one (so one matter does not become two). Matching is by words, not by meaning: every Event whose title contains the query (ignoring case) comes first, then Events whose facts, progress, refs or recorded words contain it, then Events that hold every word of the query. Returns {events} in brief, as in the directory, best matches first. Filter by state (a state, "open" or "closed"); limit caps the number returned.
Inputs: query (required), limit, state.
event_undo_revisionADestructive
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_sinceARead-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
Scored across 14 tools
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.
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).
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.
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
Related MCP Connectors
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Persistent, verbatim, searchable memory for AI assistants — one memory across every MCP client.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server for AI agents to read, write, and organize notes in a local-first, human-in-the-loop note-taking app.9 npm2MIT

datacore-mcpofficial
AlicenseAqualityBmaintenanceMCP server exposing Datacore's knowledge base, GTD, and engram memory to any AI assistant.522 npmMIT- FlicenseNot gradedqualityCmaintenanceA remote MCP server that gives AI assistants a shared memory, enabling structured handoffs, journaling, and notes for seamless continuation across sessions.-
- AlicenseAqualityBmaintenancePersistent 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.10MIT