SilverBullet

io.github.wicahmav1.0.0Updated Oct 4, 2026

List, read, write, append, delete and search markdown pages in a SilverBullet space.

Overview

AI-generated overview

Gives an assistant read and write access to markdown pages in a SilverBullet space through six note tools.

What it does
A small bridge that forwards MCP tool calls to a SilverBullet instance's built-in /.fs HTTP API. It exposes six tools: list_pages, read_note, write_note, append_note, delete_note and search_notes, the last doing case-insensitive substring search returning path, line and text. Paths are space-relative, restricted to .md, and traversal segments are rejected. It runs over stdio or streamable HTTP.
When to use it
Use it when an assistant should read, create, append to, overwrite, delete or search notes in an existing SilverBullet space, for example to draft or update pages from a chat client. It is not needed if you only want to browse SilverBullet yourself.
Requirements
A local runtime: Node.js for the npm package (npx silverbullet-mcp) or Python 3, since the npm wrapper launches a Python script. A reachable SilverBullet instance whose /.fs API is exposed, set via SB_URL. In HTTP mode an MCP_TOKEN bearer token is required; SB_AUTH_TOKEN is optional upstream auth. Network access to the instance.
Before you install
Anyone who can reach the HTTP endpoint can read, overwrite and delete every page, so do not expose it without MCP_TOKEN. write_note overwrites with no revision history, and delete_note removes pages. SB_AUTH_TOKEN alone may not enable authentication on recent SilverBullet builds, so gate access at the bridge or reverse proxy. search_notes reads every page on each call; the bridge itself stores nothing.

Installation

In SourceWeft

  1. Open SilverBullet in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

silverbullet-mcp

A tiny MCP server that gives any MCP-capable agent read/write access to a SilverBullet space.

No dependencies — Python 3 stdlib only. It is a translator: it forwards MCP tool calls to SilverBullet's built-in /.fs HTTP API, which already supports read, write and delete. Nothing needs to be installed or patched inside SilverBullet.

It is small enough to read in one sitting, and it speaks both MCP transports that clients actually use: stdio (spawned by Claude Desktop, Cursor, and friends) and streamable HTTP (shared or remote access behind a reverse proxy).

Quick start

Run it as a server:

bash
git clone https://github.com/wicahma/silverbullet-mcp.gitcd silverbullet-mcpcp .env.example .env      # set MCP_TOKEN, and SB_URL if SilverBullet is elsewhereset -a; . ./.env; set +apython3 sb_mcp.py         # streamable HTTP on http://127.0.0.1:9339/mcp

Or let a client spawn it — no clone required, since it ships on npm:

bash
SB_URL=http://127.0.0.1:8123 npx -y silverbullet-mcp --stdio

Tools

ToolArgumentsWhat it does
list_pages—list every markdown page
read_notepathread a page
write_notepath, contentcreate or overwrite a page
append_notepath, contentappend, creating the page if absent
delete_notepathdelete a page
search_notesquerycase-insensitive substring search, returns path:line: text

Paths are space-relative (Projects/Foo.md), restricted to .md, and .. segments are rejected.

Transports

stdiostreamable HTTP
Start--stdio, or MCP_STDIO=1default
Framingnewline-delimited JSON-RPC on stdin/stdoutPOST /mcp
Authnone — the client already owns the processAuthorization: Bearer $MCP_TOKEN
Good forClaude Desktop, Cursor, any client that spawns the serverremote or shared access, reverse proxies, several clients

Both come from the same code and expose the same six tools. MCP_TOKEN only matters in HTTP mode; the SB_* variables describe the upstream space in both.

Client setup

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

json
{  "mcpServers": {    "silverbullet": {      "command": "npx",      "args": ["-y", "silverbullet-mcp", "--stdio"],      "env": { "SB_URL": "http://127.0.0.1:8123" }    }  }}

Cursor

Same body, in .cursor/mcp.json for one project or ~/.cursor/mcp.json globally.

Any client that speaks remote MCP

json
{  "mcpServers": {    "silverbullet": {      "type": "http",      "url": "https://your-host.example/mcp",      "headers": { "Authorization": "Bearer <MCP_TOKEN>" }    }  }}

Local, with no reverse proxy in front:

json
{  "mcpServers": {    "silverbullet": {      "type": "http",      "url": "http://127.0.0.1:9339/mcp",      "headers": { "Authorization": "Bearer <MCP_TOKEN>" }    }  }}

Note for remote clients: url must be, or must proxy to, this bridge — not SilverBullet itself. SilverBullet has no MCP endpoint of its own; that is what this project adds.

Configuration

All configuration is environment variables, so the same code runs for anyone.

VariableDefaultMeaning
MCP_TOKEN(empty)Required in HTTP mode. Bearer token clients must send. Generate with python3 -c "import secrets; print(secrets.token_urlsafe(32))"
SB_URLhttp://127.0.0.1:8123SilverBullet base URL. Must expose /.fs
SB_AUTH_TOKEN(empty)Optional. Sent to SilverBullet as Authorization: Bearer ...
SB_USER_AGENTsilverbullet-mcp/1.0Sent on upstream calls. Some CDNs answer Python's default urllib signature with 403 / error 1010
MCP_HOST127.0.0.1Bind address
MCP_PORT9339Bind port
MCP_STDIO(unset)Any value switches to stdio, same as --stdio

HTTP endpoints

  • POST /mcp — JSON-RPC 2.0. Bearer token required. A notification returns 202.
  • GET /health (also GET /mcp/health) — {"status":"ok"}, no auth, no internal details.

Protocol versions negotiated: 2024-11-05, 2025-03-26, 2025-06-18. Maximum request body 4 MB. Batch arrays are accepted.

Auth

The bearer token is the gate. Fail closed: if MCP_TOKEN is set, every request without a matching token is rejected. If it is unset the server still starts (for local debugging) but logs a loud warning.

Do not expose this server to the internet without a token. Anyone who can reach /mcp can read, overwrite and delete every page in the space.

SilverBullet's own auth

Setting SB_AUTH_TOKEN alone on recent SilverBullet builds (verified on the 2.10.0 Rust build) does not enable authentication — anonymous requests still succeed. Per upstream docs the token is only an alternative bearer path; the server actually enforces auth when SB_USER is configured. If in doubt, probe your own instance with a deliberately wrong bearer token: if it still returns 200, auth is off.

Practical consequence: put the token gate at this bridge (or at your reverse proxy), not at SilverBullet.

Deployment

systemd user unit

ini
[Unit]Description=SilverBullet MCP bridgeAfter=network-online.target
[Service]EnvironmentFile=%h/silverbullet-mcp.envWorkingDirectory=%h/silverbullet-mcpExecStart=/usr/bin/python3 sb_mcp.pyRestart=on-failure
[Install]WantedBy=default.target

Keep the env file mode 600.

Behind a reverse proxy

Works fine behind Cloudflare Tunnel, nginx, Caddy, etc. Two notes from real deployments, both learned the hard way:

  • Route by path on an existing hostname if you are on a free TLS plan: some providers issue certificates for the apex and a single subdomain level only, so a two-level hostname may fail the TLS handshake. A path route on an already-covered host avoids that entirely.
  • Machine clients cannot complete SSO. If your host sits behind an identity-aware proxy (Cloudflare Access and similar), bypass the MCP path and let the bearer token be the gate. This is the usual split: the SilverBullet UI and its /.fs API stay behind SSO, while /mcp is public but token-gated.

Troubleshooting

SymptomCause
401 unauthorizedMissing or wrong MCP_TOKEN in the client's header
403 with error code: 1010A CDN/WAF rejected the upstream request signature. Set SB_USER_AGENT to an identifying value, and allow machine clients on the API path
Upstream replies with an HTML sign-in page, or the bridge reports JSONDecodeErrorSB_URL points at a UI that is behind SSO. Point it at an address where /.fs is actually reachable (localhost, or an internal hostname)
HttpError 500 / 502 mentioning upstreamThe bridge is fine; SilverBullet is down or SB_AUTH_TOKEN is wrong
Tools missing in the client after editing configRestart the client — MCP servers are connected at startup
npx exits immediatelypython3 is not on PATH; the npm wrapper is only a launcher for sb_mcp.py

Security notes

  • Paths are restricted to .md and .. traversal segments are rejected.
  • write_note overwrites with no revision history.
  • Binds to loopback by default; the reverse proxy is the sole ingress.
  • search_notes reads every page on each call. There is no index.
  • The bridge stores nothing. It holds no state beyond the environment it was started with, so a restart is always safe.

Distribution

Published as an npm package and as an agent plugin from this same repository.

bash
npm publish --access public     # package "silverbullet-mcp"

server.json is the official MCP Registry entry (schema 2025-12-11): the npm package, run over stdio. It deliberately declares no remote endpoint — that is each deployment's own URL, so add a remotes entry if you want yours listed.

bash
brew install mcp-publishermcp-publisher login githubmcp-publisher validate          # validates server.jsonmcp-publisher publish

The registry name is reverse-DNS and must match the publishing GitHub account: replace OWNER in server.json ("name") and package.json ("mcpName") with your GitHub login before publishing — the two must be identical.

Agent plugin manifests live at .zcode-plugin/plugin.json (ZCode) and .claude-plugin/plugin.json + .claude-plugin/marketplace.json (Claude Code and the skills.sh layout). The plugin ships the MCP server plus skills/silverbullet-mcp/, and reads the bearer token from the client's user config as mcp_token, so no secret is stored in the repository.

License

MIT

Source: README.md at commit 3fdfc9c

Tools

0
Tool metadata has not been indexed yet.

Version history

1
  1. v1.0.0LatestOct 4, 2026