[FEATURE] Add MCPJAM_OFFLINE env variable to disable all external data transmission when running locally

[adolfoweloy]

Feature

• Provide a way to opt-out from sending data to external services and APIs
• Document this behaviour for transparency

Context

Running MCPJam Inspector locally — via npx @mcpjam/inspector or npm run start — silently transmits data to four external servers without any documentation or opt-in (that I could find in the docs):

• MCPJam API for login purposes
• Sentry captures UI errors and full session replays
• PostHog tracks every feature interaction, tab visit, tool call, and model selection
• Convex (MCPJam backend) receives your MCP server's tool schemas on every chat session for token counting — this happens regardless of whether you are using a MCPJam-provided free model or your own API key (OpenAI, Anthropic, etc.). I didn't check this but it seems that full conversation history is also sent to Convex after every completed chat session. The only exception is locally-run models with unrecognized names (e.g. Ollama's llama3.1:8b) — since those don't appear in the internal model ID mapping table, a local estimator is used instead.

For teams using MCPJam internally with proprietary MCP servers, this means tool names, schemas, and potentially full chat content leave the machine on every session without any warning.

Suggestion

If we can't have this feature, it would be nice to at least have what I described above in the README.md for transparency.

Solution

A single environment variable MCPJAM_OFFLINE=true that disables all external data transmission at runtime, without requiring a rebuild of the client bundle.

When set, the flag would disable:

• Sentry initialization entirely
• PostHog event capture
• Convex tokenizer calls (fall back to local character-based estimator)
• MCPJam free model routing through Convex
• Chat session ingestion to Convex
• Tunnels, evals, and guest auth provisioning

I started experimenting with a branch in my forked version of this repo, but the change seems very fundamental.

Alternatives

Instead of using an environment variable, the same option could be provided via -- options.

Additional Context

N/A