npm slivingdocstdioMITupdated 9d ago
Distributed durable notebook built for high scale agents.
What can you do with slivingdoc?
Test coverage: 83.0% šš
Features
- Gitlike semantics:
slivingdocuses 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<semver>-<os>-<arch>) 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:
| Tool | Inputs | Success result |
|---|---|---|
notes_pull |
path (optional) |
OK |
notes_commit |
message, path (optional) |
OK |
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.
notes_pull writes the current notebook into your directory.
notes_commit 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, and a totals
trailer. A domain error exits nonzero and prints a candid report: the
error category, the retryable verdict, and every conflicted file with its
line ranges. Colour appears only on a real terminal and is disabled by
any non-empty NO_COLOR.
The git part
Letting all agents write at once would work, but they would get overrun by race conditions.
So slivingdoc has built-in git via libgit2 which effectively
does:
git pull- (potential conflict resolution locally)
git add .git commit -m "<agent message>"git push- (potential conflict resolution locally)
All of these git operations are handled locally within a private mirror of the notes directory
leaving a "streamlined" git sequence. This works due to two compromises, firstly that the local
notes directory is prone to be changed on notes_pull, precedence goes to the remote state, leaving
conflict markers. Secondly, the system only works for text (clean UTF-8).
Configuration
serve, pull, and commit read the same flags and environment
variables. --bucket is required. The most common flags:
| Flag | Environment | Default |
|---|---|---|
--bucket |
SLIVINGDOC_BUCKET |
ā (required) |
--workspace-root |
SLIVINGDOC_WORKSPACE_ROOT |
temporary dir1 |
--endpoint |
AWS_ENDPOINT_URL_S3 |
AWS resolution |
--region |
AWS_REGION |
us-east-1 |
slivingdoc serve -h prints the full reference, and
docs/running.md covers everything an operator
needs: all flags, the exact S3 permissions, logging (LOG_LEVEL on
stderr), the notebook rules, conflict recovery, and checkpoint
retention. The Terraform module in terraform/
provisions a bucket and a least-privilege IAM user for one notebook.
Development
AGENTS.mdā the developer and agent guide: package map, operation flows, conventions, and the QA gates.docs/slivingdoc-v1.mdā the accepted architecture contract.docs/build.mdā the native build, from pinned libgit2 source to dependency inspection.docs/testing.mdā the test commands, the test layers, and the no-live-AWS rule.docs/releasing.mdā release artifacts, npm trusted publishing, andmake release.
make qa #lint plus the full Go and npm test suites
License
MIT ā see LICENSE. Third-party notices for the statically linked libgit2 are in NOTICE.
Not affiliated with Paris Hilton.
Footnotes
-
servewith no configured root takes a per-process temporary notebook directory and removes it at shutdown; the notes themselves live in the bucket.pullandcommitdefault to the working directory. ā©
Install
Add slivingdoc to your client. Pick the one you use.
claude mcp add slivingdoc -- npx -y slivingdoccodex mcp add slivingdoc -- npx -y slivingdocamp mcp add slivingdoc -- npx -y slivingdoc{
"mcpServers": {
"slivingdoc": {
"command": "npx",
"args": [
"-y",
"slivingdoc"
]
}
}
}Add to `claude_desktop_config.json`, then restart Claude Desktop.
{
"mcpServers": {
"slivingdoc": {
"command": "npx",
"args": [
"-y",
"slivingdoc"
]
}
}
}Add to `~/.cursor/mcp.json`, or `.cursor/mcp.json` for a single project.
code --add-mcp '{"name":"slivingdoc","command":"npx","args":["-y","slivingdoc"]}'Or add the block manually to `.vscode/mcp.json` under `servers`.
{
"mcpServers": {
"slivingdoc": {
"command": "npx",
"args": [
"-y",
"slivingdoc"
]
}
}
}Add to `~/.codeium/windsurf/mcp_config.json`.
{
"mcpServers": {
"slivingdoc": {
"command": "npx",
"args": [
"-y",
"slivingdoc"
]
}
}
}Add to `cline_mcp_settings.json` via the MCP Servers panel.
{
"mcpServers": {
"slivingdoc": {
"command": "npx",
"args": [
"-y",
"slivingdoc"
]
}
}
}Add to `~/.gemini/settings.json`.
{
"mcpServers": {
"slivingdoc": {
"type": "local",
"command": "npx",
"args": [
"-y",
"slivingdoc"
],
"tools": [
"*"
]
}
}
}Add to `~/.copilot/mcp-config.json`, or run `/mcp add` inside the CLI.
{
"context_servers": {
"slivingdoc": {
"command": {
"path": "npx",
"args": [
"-y",
"slivingdoc"
]
}
}
}
}Add to your Zed `settings.json`.
npx -y slivingdocRun `goose configure`, choose **Add Extension ā Command-line Extension**, and paste this command.
Score
39 / 100
Incomplete
- Documentation25/25
- Maintenance25/25
- Trust13/20
- Capability0/15
- Install experience12/15
- Documents what it does and how to connect
- Has a resolvable package or endpoint
- Exposes at least one tool, prompt or resource
- README has substantive content
- Includes a code example
- Documents its configuration
- Mentions credentials or security posture
- Last commit 2 days ago
- Has a release history
- Repository is not archived
- Licensed MIT
- Namespace verified in the official MCP registry
- Claimed by its owner
- Published under an organisation
- 0 tool(s) documented
- Provides prompt templates
- Provides resources
- 12 documented install method(s)
- Published to a package registry
- Offers a hosted endpoint ā no local install
Version history
| Versions | Published |
|---|---|
| 0.1.12Latest | Aug 28, 2026 |
| 0.1.11 | Aug 28, 2026 |
| 0.1.10 | Aug 26, 2026 |
| 0.1.9 | Aug 26, 2026 |
| 0.1.8 | Aug 26, 2026 |
| 0.1.7 | Aug 25, 2026 |
| 0.1.6-rc0 | Aug 18, 2026 |
| 0.1.5 | Aug 18, 2026 |