# slivingdoc

> An MCP server for people and agents to share notes. Write in parallel, merge concurrent changes with Git semantics, and persist the notebook in an 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 in an 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](/docs/guides/mcp-hosts/).
- **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](/docs/concepts/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](/docs/guides/path-policies/#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](/docs/guides/path-policies/#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](/docs/guides/cli/#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](/docs/guides/shared-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.

## Shortest working setup

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

```text
export SLIVINGDOC_BUCKET=<your-bucket>
slivingdoc serve
```

See [Installation](/docs/installation/) and
[Quickstart](/docs/quickstart/) for a full walkthrough, or
[Configuration](/docs/reference/configuration/) for every flag,
environment variable, and default.

## Where to go next

- [Guides](/docs/guides/mcp-hosts/): 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](/docs/concepts/how-it-works/): how it works, the storage
  model, guarantees and limits.
- [Reference](/docs/reference/cli/): the CLI, the MCP tools, configuration,
  errors, S3 requirements, logging and profiling.