ContextBridge MCP Server

MCP memory server for AI coding assistants. Windows Service, ONNX embeddings, SQLite vector search. The contextbridge mcp server wraps that behind the Model Context Protocol, so an assistant can use it through 14 defined tools rather than through you.

What it actually does

A zero-dependency MCP memory server for Windows that gives AI coding assistants a shared, persistent memory layer with semantic search.

AI coding assistants like Claude Code are stateless—each session starts fresh, with no persistent memory of your prior context, decisions, or discoveries. ContextBridge solves this by running as a background Windows Service that all your AI tools connect to. It stores memories persistently, searchable by meaning (not keywords), so context accumulates across sessions and across different tools simultaneously.

• Zero external dependencies — — No Docker, Postgres, Python, or Ollama. Everything runs in one Windows Service process
• In-process embeddings — — Embedding model (all-MiniLM-L6-v2, ~22 MB) runs via ONNX Runtime; no external API calls
• Single-file storage — — SQLite database at %ProgramData%\ContextBridge\memories.db. Backup is one file copy
• Shared across tools — — Claude Code (HTTP), Claude Desktop (stdio), Cline, VS Code Chat Agents all connect to the same memory store in real-time
• Memory survives service restarts — — Memories persist in SQLite; the embedding model loads once on startup and stays warm

Its toolset

Everything the assistant can do here goes through one of these:

• project — — scope memories to a project
• type — decision — architectural or technology choices
• content — the session summary (free-form text)
• ttl_days — how many days to keep the handoff before auto-expiry (default: 7)
• memory_write — Store a single memory with automatic semantic embedding and optional tags
• memory_batch_write — Store multiple related memories atomically (efficient end-of-session extraction)
• memory_search — Semantic search — natural language query, returns nearest-neighbor results
• memory_list — Paginated list of all memories with optional tag filters
• memory_update — Update a memory's content (re-embedded automatically)
• memory_delete — Delete a memory by ID
• memory_status — Service health check, record count, model info
• handoff_write — Capture session state — what you're working on, decisions made, next steps

Configuration

• Windows 10 / Windows 11 (required for Windows Service integration) - Option A: .NET 10 SDK (if installing via dotnet tool) - Option B: Windows 10+ (no additional prerequisites if downloading a pre-built .exe) - Admin PowerShell (required to install/uninstall the Windows Service)

Adding it to your client

Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client.

When to reach for it

Plenty of knowledge and memory servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. ContextBridge's toolset — project, type, content and 11 more — is a fair guide to whether it matches your workflow. It is maintained by ThunderEagle; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.

Caveats

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• With 14 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch ContextBridge.
• MCP clients confirm each tool call by default. Leave that on until you have watched what the contextbridge mcp server does with a few real requests.