slivingdoc MCP server

Test coverage: 84.6% 😍👌

Distributed durable notebook built for high scale agents.

Features

• Gitlike semantics: slivingdoc uses terminology we (and agents) all know, designed for ease of use
• Automatic conflict resolution: commit without fear, trust that all conflicts must be resolved before being accepted
• High speed processing: the solution is quite simple conceptually, allowing for very high scale and parallelism
• Plug-and-play: setup the bucket, point at it, and start syncing notes!

docs/slivingdoc-v1.md is the full accepted contract behind these guarantees.

Get started

Add it to your agentic harness:

{
  "mcpServers": {
    "slivingdoc": {
      "command": "npx",
      "args": ["-y", "slivingdoc", "serve", "--bucket", "my-notes"],
      "env": {
        "AWS_ACCESS_KEY_ID": "<your-access-key-id>",
        "AWS_SECRET_ACCESS_KEY": "<your-secret-access-key>",
        "AWS_REGION": "us-east-1"
      }
    }
  }
}

The bucket must exist, and credentials come from the normal AWS chain. No S3 account yet? examples/seaweedfs/ runs a local SeaweedFS container with a step-by-step walkthrough. You can also download a native binary directly from the GitHub release (slivingdoc-v--) and run it in place.

Supported platforms: Linux (amd64, 32-bit ARMv7, arm64), macOS (amd64, arm64), and Windows (amd64). The 32-bit Linux ARM artifact supports Raspberry Pi OS armhf.

How it works

The server exposes two MCP tools over stdio:

No path needed. Each server takes its own private notebook directory and tells the agent where it is, in the server instructions and in every tool result, so nothing has to be configured or coordinated between agents. Pass --workspace-root instead when you want a fixed directory that humans and agents share, and path then addresses any directory below it.

notespull writes the current notebook into your directory. notescommit publishes your changes and incorporates concurrent non-conflicting changes. Between calls there is no protocol at all — agents edit the files with the tools they already have, and humans can write in the same directory with any editor. The next commit carries their changes too.

Humans can also drive both operations directly, without an MCP host. The path is optional and defaults to the working directory; a relative path resolves against it:

slivingdoc pull notes
# edit UTF-8 text files under notes/
slivingdoc commit notes -m "meeting summary"

Success prints the unified result report: the OK status, the accepted remote generation, per-file insertion and deletion counts, a totals trailer, and a read-only: trailer when the process has a configured read-only set. A domain error exits nonzero and prints a candid report: the status line (the error code, a middle dot, and the reason token), the message, every affected file with its reason and line ranges, a next: line naming the caller's next step, the retryable verdict, and the same read-only trailer when configured. Colour appears only on a real terminal and is disabled by any non-empty NO_COLOR. MCP errors provide the same essential fields in their text item, including a diagnostic ID for server-log correlation. An engine failure adds a plain-language detail when the engine could name the cause; otherwise the cause stays in the server log, which the diagnostic ID points at.

Shortened. The full README is on GitHub.