The MCP door: notes in a sealed store your person owns.

• One local MCP server, arcaeon-seal-mcp, over stdio, in the desktop app (in an earlier release).
• Exactly eight tools: record_write, record_read, record_correct, record_verify, record_pin, record_export, record_packet, record_stamp.
• It speaks for one store folder, named with --root (or SEAL_ROOT). It never reads or writes outside it.
• In every tool, namespace is the note's name: its path in the store's notes folder, such as todo.txt. It is not the store's own namespace.
• Every row number is a ledger row: its place in the store's one ledger, counting from 0, not a count within one note.

A client that has the folder can still read a flagged note off the disk; the door flags it and holds the text back, it cannot stop a client that goes around it.

The desktop app installs the door (in an earlier release) and the seal checker in the app folder, and makes the store folder:

• Door: C:\Users\YOU\AppData\Local\Programs\Arcaeon\arcaeon-seal-mcp.exe
• Seal checker: C:\Users\YOU\AppData\Local\Programs\Arcaeon\seal.exe
• Store: C:\Users\YOU\AppData\Local\ArcaeonDoor\store (kept apart from the app's own folder; uninstall keeps it)

Add this inside mcpServers. Full paths, every backslash written twice:

{
  "mcpServers": {
    "arcaeon-seal-mcp": {
      "command": "C:\\Users\\YOU\\AppData\\Local\\Programs\\Arcaeon\\arcaeon-seal-mcp.exe",
      "args": ["--root", "C:\\Users\\YOU\\AppData\\Local\\ArcaeonDoor\\store"]
    }
  }
}

Restart the host fully. Listing the tools from arcaeon-seal-mcp should show eight. The store folder must already exist: the door never makes one, and will not start without it. A quick check that it starts: arcaeon-seal-mcp.exe --help prints a usage line with --root ROOT.

OK

The store (or the packet) passed every check.

EMPTY

The store has no rows yet. Nothing is vouched for. record_pin and record_packet refuse an empty store.

BROKEN at ledger row N (or BROKEN)

The store failed its check. problems lists each as {code, row, text}. The verdict covers the whole store, so a read of any note is red while one note is broken.

STALE_PIN

The store passed on its own but does not agree with its pins.

UNVERIFIED

From a packet check: a step the packet cannot check alone. Never a pass. A packet names a witness time only when it is tied directly to the point the witness signed; any other packet is UNVERIFIED for the time and names none.

FAIL

From a packet check: a hash does not hold. record_packet turns a FAIL into a refusal, never a success.

Red first. record_read verifies before it answers. When the verdict is not OK, rows and text are withheld unless you pass rely_on_red=true, and then every row is flagged and text comes with text_flagged: true. Do not repair a red store, and do not ask your person to let you. Tell them.

Refusals. A result with "refused": true (and reason) means nothing was done. It is sent with isError: true. A red verdict is a normal result, not an error. Refusals that need a person start with "This needs a person at this computer:".

• Never uses the network for notes. Notes stay in the store folder on this computer.
• Never reads or writes outside its one store. Links, device names, drive letters, absolute paths and .. in a note name are refused.
• Never deletes or rewrites. Write and correct only add rows; pin, export and packet only add files.
• Never fakes success. When it cannot do what was asked, it refuses.
• Never claims a note is true, or who wrote it. The seal proves rows were not altered after writing.
• Never claims a witness on this store: record_pin on the door's own store makes a local pin, and nobody outside this computer saw it.

Tool hints: read and verify are read only. Only record_pin is marked open world, because on a folder the desktop app keeps, the app's own Pin now may reach its witness with a fingerprint. The door's own store is not such a folder.