Documentation

How ContextBridge works

A developer's guide to the bridge pipeline, semantic memory layer, MCP server tools, and REST API.

Overview

ContextBridge has three surfaces built on the same engine:

Architecture

  [ share link / capture / add_memory ]
                  |
                  v
        [ ContextBridge server ]
          fetch → decode → store
                  |
          ┌───────┴────────┐
          v                v
    [ conversation ]  [ embedding index ]
          |                |
          v                v
    website / API     /memory search
                      MCP search_memory

The website bridge

When you paste a share link, ContextBridge runs a deterministic pipeline:

Semantic memory

Every conversation bridged — via share link, bookmarklet, or add_memory — is automatically embedded using Xenova/all-MiniLM-L6-v2, a 80 MB ONNX model that runs locally in Node.js. No OpenAI key, no external embedding API.

Embeddings are stored alongside conversations (disk or GCS) and searched by cosine similarity. The Memory page gives you a live search UI; search_memory exposes the same index to any MCP agent.

POST /api/memory/search
{ "query": "useEffect infinite loop", "limit": 6 }

→ { results: [{ convId, title, source, role, text, score }] }

GET /api/memory
→ { memories: [{ convId, title, source, turns, indexedAt }] }

The MCP server

The Model Context Protocol (MCP) is an open standard for connecting AI apps to external tools. Add the ContextBridge MCP server config and any compatible agent can call its tools directly.

Run the server locally, pointing at the hosted API:

# clone the repo or install the mcp package
node /path/to/context-bridge/mcp/index.mjs

# or in your MCP client config:
{
  "mcpServers": {
    "contextbridge": {
      "command": "node",
      "args": ["/absolute/path/to/mcp/index.mjs"],
      "env": { "CONTEXTBRIDGE_URL": "https://contextbridge.in" }
    }
  }
}

5 tools available today:

  • bridge_share_link(url, format?) — fetch and decode a ChatGPT share link into portable context. Returns an agent capsule by default.
  • get_context(id, format?) — return an already-bridged conversation in the format you ask for (md / json / txt / agent).
  • search_memory(query, limit?) — semantically search across every conversation you have ever bridged. Returns ranked turns with similarity scores.
  • add_memory(content, title?, source?) — save a plain-text note into the memory index. Useful for capturing decisions or context without a share link.
  • list_memories() — list all indexed conversations and notes.

See the Connect page for per-app setup steps.

REST API

All endpoints are CORS-open so browser-based agents can call them directly.

# bridge: read a conversation
GET  /api/c/{id}?format=md|json|txt|agent[&download=1]

# ingest: push any conversation in
POST /api/ingest
     { source, title, turns: [{ role, text, media? }] }

# memory: search by meaning
POST /api/memory/search
     { query: string, limit?: number }

# memory: list all
GET  /api/memory

Media handling

Images uploaded into a chat are stored by the provider behind opaque pointers with no public URL. The bridge therefore carries image references — position, dimensions, a link to the original — rather than raw bytes. The bookmarklet on the Capture page runs in your browser where images are already loaded, so it can carry the real rendered URLs across.

Data & privacy

Share-link bridging is stateless by default — the share link is the source of truth. When you use memory (bridge, ingest, or add_memory), the conversation and its embeddings are stored in /tmp on the server instance, or in a GCS bucket if you configure GCS_BUCKET + GCP_SA_KEY. Nothing is shared with third parties. The project is MIT licensed.

Roadmap

Connect an app Search memory