Claude can read my files, my terminal, even my screen. But it had no idea what I read in my browser yesterday.
That gap bugged me enough to build ** BraveMCP**: a local-first "second brain" that gives Claude Desktop access to my browsing history, bookmarks, highlights, and notes through the Model Context Protocol (MCP). Everything stays on my machine. No cloud, no tracking.
This is the technical write-up: the architecture, the one constraint that shaped the whole design, and the bugs that cost me the most time.
MCP servers talk to Claude Desktop over stdio, a JSON-RPC stream on stdin/stdout. A browser extension lives in a sandbox and cannot speak stdio. It can only make outbound HTTP requests.
So the two halves of the system physically cannot talk to each other directly. That single fact drove the entire design.
The fix is a small HTTP bridge: an Express server running on port 3747
, inside the same process as the MCP server. The extension POSTs browsing events to it; the MCP server reads from the shared database when Claude calls a tool.
Keyword search and semantic search each miss things the other catches. So BraveMCP runs both and merges them.
// Merge keyword + vector hits; boost items that appear in both
const merged = new Map();
for (const m of chromaMatches) merged.set(m.id, { ...m, source: "semantic" });
for (const m of ftsMatches) {
const existing = merged.get(m.id);
if (existing) existing.relevance *= 1.1; // appears in both -> boost
else merged.set(m.id, { ...m, source: "keyword" });
}
If ChromaDB is not running, the server degrades to FTS5-only instead of failing. Local-first means it has to work with whatever services you actually have up.
When a page is captured, BraveMCP generates a summary and an embedding. It tries Ollama first (fully local: llama3.2
for summaries, nomic-embed-text
for embeddings), then falls back to the Anthropic API.
But here is the trap I walked into. The first version, when no LLM was available, returned canned strings:
// before: this ignores the actual data entirely
return `Synthesis on "${topic}": Relies on the gathered browser research database.`;
That is useless. It says the same thing no matter what you searched. So I rewrote every fallback to be extractive: to build a real summary from the actual data, grouping matching pages by domain with real snippets pulled from SQLite. With no LLM at all, asking for a topic synthesis now returns the genuine sources. Different input produces different output. The "AI" tools stay useful even when there is no AI running.
The tool I use most is find_forgotten_content
. You give it a vague description and it does hybrid search, then re-ranks with time decay and a visit-count boost:
const timeDecay = Math.max(0.5, Math.exp(-0.01 * daysElapsed));
const visitBoost = 1 + 0.2 * Math.log(visitCount);
const adjusted = Math.min(0.99, relevance * timeDecay * visitBoost);
A page you opened three times last week beats one you glanced at once today. That matches how memory actually feels.
1. dotenv v17 broke the entire protocol. MCP communicates over stdout. dotenv v17 prints a status line to stdout by default. That one line corrupted the JSON-RPC channel and Claude Desktop refused to connect with a cryptic Unexpected token
error. The fix was pinning dotenv@16
. Two hours on a single log line.
2. The dual-process state problem. Claude Desktop and my dev client each spawn their own copy of the MCP server. Only the instance that grabs port 3747
receives extension data. The other had empty in-memory state, so tab tools returned nothing. The fix: stop treating in-memory state as the source of truth and fall back to SQLite, which both processes share.
search_memory
, find_forgotten_content
, summarize_research_topic
, generate_weekly_digest
, suggest_tab_cleanup
, and more)It is open source, MIT licensed: https://github.com/glatinone/BraveMCP
If you are building on MCP, the stdio-vs-HTTP bridge pattern is the part worth stealing. What would you want your AI to remember?