slivingdoc

slivingdoc

An MCP server for people and agents to share notes. Write in parallel, merge concurrent changes with Git semantics, and keep the notebook on slivingdoc.dev or in your own S3-compatible bucket.

Canonical URL: https://www.slivingdoc.dev/

Full site index: https://www.slivingdoc.dev/llms.txt

slivingdoc is a shared, durable notebook for people and agents. An MCP server exposes it to agents, and people can use the same pull and commit operations from the command line or edit the same files directly. The notebook persists on slivingdoc.dev or in your own S3-compatible bucket; Git-style merges combine concurrent, non-conflicting changes and surface conflicts instead of silently losing them.

Use cases

• One context for every coding agent. Claude Code, Codex, and any other MCP host connect to the same server. Context written in one session is there in the next, whichever harness runs it. See Connect an MCP host.
• Shared state for production agents. Agents in production keep dynamic context in the notebook: what a customer needs, how far an investigation got, what was already tried. Context too loose for a schema stays plain text. See How it works.
• Fleets that report back. Spawn a large fleet and confine each agent to its own directory. Every agent commits its report, and a human pulls the notebook to read them all in one place. See Writable paths.
• Prompts you change at runtime. Serve instructions to agents from read-only paths. Edit them from the command line, and every agent reads the new version on its next pull, with no redeploy. See Read-only paths.
• Memory for short-lived runners. CI jobs, scheduled agents, and sandboxes lose their disk after every run. The notebook lives in the bucket, so the next run starts where the last one stopped. See From scripts and cron.
• Notes between people and machines. Colleagues, and your own computers, pull and commit the same notebook from the command line and edit it with any editor. See Share a directory.

The two operations

• Pull (notes_pull over MCP, pull on the CLI): write the current notebook into a directory.
• Commit (notes_commit over MCP, commit on the CLI): publish local changes, merging in any concurrent, non-conflicting remote changes. A commit that conflicts with the remote state returns the conflict instead of silently losing it.

Two ways to start

Same CLI, same MCP server, same notebook. The only difference is who keeps the storage.

• We host it. Sign in with GitHub or Google, get a space and a token, and paste the setup into your agent. No bucket, no cloud keys, no card. Free for 10 MB and 250,000 requests a month; after that, $1 a month for each extra space, 100 MB or 250,000 requests. See Pricing.
• Run it yourself. Open source. Point the CLI or MCP server at an S3-compatible bucket with conditional writes, such as AWS S3 or SeaweedFS. Free, with nothing to sign up for. The setup follows.

Run it yourself

Point an MCP host at the server, or run the CLI directly, against an S3-compatible bucket:

export SLIVINGDOC_BUCKET=<your-bucket>
slivingdoc serve

See Installation and Quickstart for a full walkthrough, or Configuration for every flag, environment variable, and default.

Where to go next

• Guides: connect an MCP host, use the CLI without one, set up a bucket, share a directory with humans, restrict agents with path policies, resolve conflicts.
• Concepts: how it works, the storage model, guarantees and limits.
• Reference: the CLI, the MCP tools, configuration, errors, S3 requirements, logging and profiling.