MCP Context Bridge

TypeScript implementation of the MCP Context Bridge server — a lightweight HTTP server that lets AI coding assistants in different IDEs (Visual Studio, IntelliJ IDEA, VS Code, etc.) share context through a single in-memory store.

---

Prerequisites

• Node.js v20.19.0 or later
• npm v10 or later

---

Setup

# Install dependencies
npm install

# Copy the example env file and adjust if needed
Copy-Item .env.example .env

Environment variables

Variable	Default	Description
HOST	127.0.0.1	Host interface the MCP HTTP server binds to
PORT	5100	Port the MCP HTTP server listens on

Edit .env to override any value:

HOST=127.0.0.1
PORT=5100

---

Development

# Build once
npm run build

# Type-check without emitting files
npm run typecheck

# Build + restart on file changes
npm run dev

# Open MCP Inspector configured for the HTTP endpoint
npm run inspect:http

# Lint
npm run lint
npm run lint:fix

# Format
npm run format
npm run format:check

---

Production

npm run build
npm start

The server starts at http://<HOST>:<PORT> with the MCP endpoint at /mcp.

---

Testing with MCP Inspector over HTTP

This server already supports the Inspector over streamable-http. You do not need stdio mode.

UI workflow

Start the bridge:

npm start

In a second terminal, start the Inspector UI with the repo config:

npm run inspect:http

The included mcp.json points the Inspector at:

http://127.0.0.1:5100/mcp

If the Inspector does not auto-select the server, choose default-server in the UI.

Notes

• The bridge process must already be running before the Inspector connects.
• The transport type is streamable-http.
• If you change HOST or PORT, update mcp.json.

---

IDE mcp.json examples

The root mcp.json in this repo is for the MCP Inspector. IDE clients use the same endpoint, but not always the same file location or top-level JSON key.

Common endpoint: http://127.0.0.1:5100/mcp

• The entry name is just a client-side label, but using mcp-context-bridge keeps it consistent with the actual server name.
• VS Code and Visual Studio use servers.
• JetBrains AI Assistant uses mcpServers.
• If you change HOST or PORT, update the URL in the client config.

VS Code

Use .vscode/mcp.json:

{
  "servers": {
    "mcp-context-bridge": {
      "type": "http",
      "url": "http://127.0.0.1:5100/mcp"
    }
  }
}

IntelliJ IDEA / JetBrains AI Assistant

In Settings | Tools | AI Assistant | Model Context Protocol (MCP), add an HTTP server and paste:

{
  "mcpServers": {
    "mcp-context-bridge": {
      "url": "http://127.0.0.1:5100/mcp"
    }
  }
}

Visual Studio

Use .mcp.json in the solution root or %USERPROFILE%\.mcp.json for a user-wide setup:

{
  "servers": {
    "mcp-context-bridge": {
      "url": "http://127.0.0.1:5100/mcp"
    }
  }
}

Visual Studio also auto-discovers .vscode/mcp.json.

---

Project structure

mcp-context-bridge/
├── src/
│   ├── index.ts              # Entry point — Express app + session routing
│   ├── BridgeTools.ts        # MCP tool registrations
│   └── SharedContextStore.ts # In-memory context store
├── .env                      # Local environment overrides (gitignored)
├── .env.example              # Committed template — copy to .env
├── .prettierrc
├── eslint.config.ts
├── tsconfig.json
├── tsup.config.ts
└── package.json

---

Available MCP tools

Tool	Description
post_context	Start a new context thread (status: pending) to share with the other IDE
reply_context	Add a reply to an existing thread — respond with results, follow-ups, etc.
update_status	Set a thread's status: pending, in-progress, or done
get_context	Read a thread including all messages and its current status
list_contexts	List all threads, optionally filtered by source or status
remove_context	Remove a thread that's no longer relevant
clear_all_contexts	Clear all threads when starting a new task

---

Example workflow: VS Code + IntelliJ IDEA

How it fits together

A single developer works on two repos — e.g. a TypeScript frontend in VS Code and a Kotlin backend in IntelliJ IDEA. Each IDE has its own AI assistant, and both connect to the same MCP Context Bridge server.

An assistant in one IDE can read source code from the other repo via a RAG tool (e.g. mcp-rag-server), but it cannot modify files there. MCP Context Bridge closes the loop: the first assistant analyses the other repo, posts what needs to change, and the second assistant picks up those instructions and applies them. GitHub Copilot is one example, but the same pattern works with other AI tools that can call MCP tools.

Parameter guide

post_context and reply_context both take three parameters:

Parameter	Purpose	Tips
key	A short topic name that identifies the thread.	Use kebab-case names like race-condition-fix, api-contract. Both assistants read/reply under the same key.
source	Labels which IDE/repo posted the message.	Use a consistent pattern like vscode-frontend, intellij-backend. Threads can be filtered by source with list_contexts.
content	The actual information to share — free-form text.	Include analysis results, code snippets, required changes, constraints, etc.

---

Step 1 — VS Code finds a race condition in the backend repo

You're working in VS Code on the frontend and notice a timing issue during integration testing. You ask your AI assistant to investigate:

Prompt (VS Code): "Use the RAG tool to search the backend repo for how OrderService.processOrder() handles concurrent requests. Check if there's a race condition."

The assistant searches the backend repo via the RAG tool, finds the problem, and you ask it to share the findings:

"Post what you found to shared context so I can fix it in IntelliJ."

The assistant calls post_context — this creates a new thread with status pending:

{
  "key": "race-condition-fix",
  "source": "vscode-frontend",
  "content": "Race condition in OrderService.processOrder() — the inventory check and decrement are not atomic. Two concurrent requests can both pass the check and oversell. File: src/main/kotlin/com/example/service/OrderService.kt, lines 42-58. Suggested fix: wrap the check-and-decrement in a @Transactional block with a SELECT FOR UPDATE on the inventory row."
}

---

Step 2 — IntelliJ picks up the analysis and applies the fix

You switch to IntelliJ and ask your AI assistant there to act on the findings:

Prompt (IntelliJ): "Check shared context for pending items, then apply the fix."

The assistant calls list_contexts with status pending, sees the race-condition-fix thread, then calls get_context to read the full analysis.

It calls update_status to mark the thread in-progress, applies the fix in OrderService.kt, and then replies under the same thread:

{
  "key": "race-condition-fix",
  "source": "intellij-backend",
  "content": "Fixed in OrderService.kt. Wrapped inventory check + decrement in @Transactional with SELECT FOR UPDATE. Also added an integration test in OrderServiceConcurrencyTest.kt that runs 50 parallel orders against a single inventory row."
}

Finally it calls update_status to mark the thread done.

---

Step 3 — VS Code confirms and updates the frontend

Back in VS Code, you check the response:

Prompt (VS Code): "Check shared context — has the race condition fix been applied?"

The assistant calls list_contexts with status done, sees the thread is complete, then calls get_context with key race-condition-fix to read the full conversation. Both the original analysis and the IntelliJ reply are in one thread. The assistant determines the frontend needs a retry with backoff for HTTP 409 (conflict) responses that the new locking may produce.

---

Step 4 — Clean up for the next task

Prompt (either IDE): "Done with the race condition fix. Clear all shared context."

The assistant calls clear_all_contexts to reset the store.

---

Notes

• The store is in-memory only — restarting the server clears all context.
• The server must be running before any IDE attempts to connect.
• All IDE connections share the same SharedContextStore instance within the process.