Obsidian MCP by fazer-ai
fazer-aiLABSCO SUMMARY
Two separate tokens, which is the right shape for this.
SB_AUTH_TOKEN is the bridge's own credential into SilverBullet and MCP_TOKEN is what a client presents — so revoking an assistant's access does not mean rotating your note-taking setup. Note that the query-parameter form puts the token in the URL, where it tends to end up in logs and shell history; prefer the Authorization header where your client supports one.
What it is
A bridge between a SilverBullet instance and MCP clients. It runs beside your SilverBullet container under Docker Compose, holds the credential that talks to SilverBullet's API, and exposes your space to external applications as standardised MCP tools and resources behind its own token — so the client authenticates to the bridge, not to SilverBullet.
What you get
- Your SilverBullet notes and data reachable through MCP tools and resources, rather than through SilverBullet's own API surface
- A Streamable HTTP endpoint at
http://localhost:4000/mcpfor clients that can send custom headers - Two accepted authentication forms: an
Authorization: Bearerheader, or a?token=query parameter appended to the endpoint URL - A stdio path for clients that cannot do HTTP, by putting
mcp-remotein front with--transport http-onlyand the token passed as a header - A Docker Compose setup that brings up both SilverBullet and the bridge together, with SilverBullet on
http://localhost:3000
Requirements
Docker and Docker Compose, plus a running SilverBullet instance — docker-compose up --build starts both. Three settings live in .env: SB_AUTH_TOKEN, the shared token between SilverBullet and the bridge; MCP_TOKEN, the token your client presents; and optionally SB_API_BASE_URL, which defaults to http://silverbullet:3000 under the provided Compose file. PORT moves the bridge off its default of 4000. The package is silverbullet-mcp-server 1.1.0. Clients that only speak stdio need mcp-remote; on Cursor and Claude Desktop on Windows, keep the header argument free of spaces, as the README's Authorization:Bearer ${MCP_SERVER_TOKEN} form does.
Setup effort
Run a container — build the image from the repository, then point your client at it
USE CASES
01
Letting an assistant work with your notes without handing over SilverBullet
Give the client only the bridge token; the credential that reaches SilverBullet stays in the bridge's environment.
02
Connecting a client that only speaks stdio
Put mcp-remote in front of the HTTP endpoint with the token passed as a header, instead of waiting for the client to support Streamable HTTP.
03
Running notes and assistant access as one deployment
Bring up SilverBullet and the bridge together with Compose, so the pair starts and stops as a unit rather than as two hand-managed processes.
BEFORE YOU INSTALL
What to know first
Requires
- Docker and Docker Compose
- SB_AUTH_TOKEN and MCP_TOKEN — two secure tokens you choose and set in .env; your client sends MCP_TOKEN as an Authorization: Bearer header
Where it runs
All 3 documented clients run the server on your machine.
INSTALLATION
Connect your client
Build the image from the repository, then point your client at it.
Server setup
TERMINAL
git clone https://github.com/Ahmad-A0/silverbullet-mcp.git
cd silverbullet-mcp
cp .env.example .envUpdate .env with your values: SB_AUTH_TOKEN (a secure token shared by SilverBullet and this server) and MCP_TOKEN (the token your client presents)
TERMINAL
docker-compose up --buildMCP Clients
Claude Desktop, Cursor, Windsurf
JSON
{
"mcpServers": {
"silverbullet-mcp": {
"command": "npx",
"args": [
"mcp-remote",
"http://localhost:4000/mcp",
"--transport",
"http-only",
"--header",
"Authorization:Bearer ${MCP_SERVER_TOKEN}"
],
"env": {
"MCP_SERVER_TOKEN": "<YOUR_MCP_SERVER_TOKEN>"
}
}
}
}Start the Docker Compose services first. <YOUR_MCP_SERVER_TOKEN> is the MCP_TOKEN value from your .env file.
