Bookmarks Mcp

bookmarks-mcp

Your bookmarks, wherever they live, readable by your AI.

Everyone saves. Browsers, read-later apps, that Pocket export from 2023 — capture is a solved problem. Processing is not: the average bookmark is saved once and never touched again. AI assistants are the first thing that can actually process a pile like that — summarize, triage, turn it into a to-do list — but they can't see it.

This is a local, read-only MCP server that fixes the "can't see it" part.

One command in your MCP client config. Zero accounts. Nothing is ever sent to us.

Sources

Phone bookmarks: reachable once they sync to your desktop (iCloud → Safari on Mac, Chrome sync → desktop profile). There is no way for any third-party tool to read Safari bookmarks directly on iOS.

Install

No account, no API key, no configuration — the server works the moment it's installed.

Claude Code:

claude mcp add -s user bookmarks -- npx -y bookmarks-mcp

Use -s user. The scope defaults to local, which only registers the server for the directory you ran the command in. Your bookmarks aren't tied to one project, so register it account-wide.

Claude Desktop / Cursor / any MCP client (mcpServers JSON):

{  "mcpServers": {    "bookmarks": {      "command": "npx",      "args": ["-y", "bookmarks-mcp"]    }  }}

To run from source instead (for development), clone this repo next to its dependency parse-bookmarks (the two directories must be siblings), run npm install in bookmarks-mcp, and point your client at node /absolute/path/to/bookmarks-mcp/src/index.js.

macOS + Safari: the app hosting the server (Claude Desktop, your terminal) needs Full Disk Access (System Settings → Privacy & Security), because ~/Library/Safari is protected. Chromium browsers and Firefox need nothing.

Tools

Turn the pile into a to-do list

The reason this exists. Ask your assistant:

Look at my bookmark stats, then help me triage: which of these become deep reads, which are tools to try, which feed a project I'm working on, and which should I finally let go? Give me a checklist for this week.

Or use the built-in triage_bookmarks prompt, which walks through exactly that — including asking you to define what your saves usually become, so the lanes are yours, not ours.

Guarantees

• Read-only. This server never writes to a browser file. There is no delete tool. Your bookmarks cannot be harmed.
• Zero phone-home. No telemetry, no accounts, and not a single byte sent to us. The server talks to exactly two places: your local bookmark files, and — only when you ask it to preview a page — the bookmarked site itself, directly from your machine.
• Clean output. Tool results are data. No ads, no upsells, ever.

Design boundaries

These are deliberate, not gaps waiting to be filled. PRs that cross them will be declined:

• Preview-level extraction only. fetch_page_preview answers "is this worth my time" — it is not a reader mode and never will be a full-fidelity content extractor.
• Public web pages only. No proxies, no login walls, no special-casing for X/YouTube/WeChat/etc. If a page needs auth to read, this tool isn't the way in.
• On-demand only. Nothing fetches in the background, ever. Every network call is a direct response to a tool call you made.

Roadmap

• Cloud sources behind user-supplied tokens (Raindrop, Readwise, …) — one adapter per service. PRs welcome; an adapter is a single well-defined file.
• Services that already ship their own MCP server don't need us — run both servers and your assistant sees everything. We only cover the places that have no other bridge.

Who makes this

Built by the team behind Burn 451, a read-later app. This server is deliberately neutral: it reads your bookmarks for whatever assistant and whatever workflow you choose, and it never writes to them.

License

MIT