Janusmcp

JanusMCP

One credential broker. Every account. From the CLI or MCP. Multi-account tool access for AI agents, with credentials kept local.

One-click buttons require the npm package to be published. See RELEASING.md .

The problem

If you work with more than one company, you use the *same* MCP server (Supabase, GitHub, Slack…) with different identities — a different account, email and token per client. Today most LLM clients hold one account at a time per connector: to switch client you disconnect, reconnect, and redo the OAuth login. Every time.

The MCP protocol has no notion of "account": one session = one identity = one set of credentials. JanusMCP fills that gap.

What it does

JanusMCP is a local multi-account tool broker for AI agents. It can be used directly from the CLI or as an MCP server in front of the real upstream servers:

• Add N accounts once for the same service and keep them all available.
• Switch identity without reconnecting — no re-login, no fiddling with config.
• Works with any LLM client — it just speaks standard MCP (stdio + Streamable HTTP).
• Works without an MCP session too — agents can drive it directly from the CLI (code-execution mode): janusmcp tools / schema / call invoke tools on demand, with no bulk tool definitions loaded upfront.
• Runs locally — your machine, your keychain, your control.
• Keeps the context clean — it exposes only the *active* account's tools, not N×tools.

                 ┌─────────────────────────────┐   ┌─ Supabase (Client A)

LLM client ─MCP─▶│ JanusMCP broker │─▶ ├─ Supabase (Client B) (Claude/GPT/ │ active-account · vault · │ ├─ GitHub (Client A) Gemini/…) │ per-session scoping │ └─ … └─────────────────────────────┘

You drive it with three control tools that appear in any client: janus_list_accounts, janus_use_account, janus_whoami.

Choose your mode

Use from the CLI — Claude Code, Codex, Cursor, scripts

npm install -g @bayway/janusmcp

janusmcp tools janusmcp schema list_tables janusmcp call list_tables --args '{"schemas":["public"]}' --json --timeout 30s

The CLI discovers schemas only when needed, accepts JSON through --args or stdin, supports explicit accounts/profiles, and provides stable exit codes. See the CLI guide and copyable agent instructions.

Connect over MCP — desktop and chat clients

npx @bayway/janusmcp serve

or configure a supported client automatically:

janusmcp install claude-desktop

Both modes share the same config, OS-keychain vault, OAuth tokens and persisted active account. Use janusmcp daemon start to keep upstream sessions warm across repeated CLI calls.

Install

Once released, install via your favorite channel (all published automatically on each tag — see RELEASING.md):

npx @bayway/janusmcp serve                       # npm / MCP mode

brew install bayway/janusmcp/janusmcp # Homebrew (macOS/Linux) scoop install janusmcp # Windows docker run --rm -p 7332:7332 ghcr.io/bayway/janusmcp:latest

…or download a prebuilt binary from Releases.

Build from source (60-second quickstart)

git clone https://github.com/bayway/janusmcp

cd janusmcp/go make build # produces ./bin/janusmcp cp config.example.json config.json # edit with your accounts ./bin/janusmcp serve # stdio, for Claude Desktop/Code

Two Supabase clients, PATs kept in your OS keychain (never in the config):

./bin/janusmcp vault set supabase_client_a   # paste the PAT

./bin/janusmcp vault set supabase_client_b

// config.json

{ "bindingMode": "session", "accounts": [ { "id": "client_a", "service": "supabase", "command": "npx", "args": ["-y", "@supabase/mcp-server-supabase@latest", "--read-only", "--project-ref=REF_A"], "env": { "SUPABASE_ACCESS_TOKEN": "vault:supabase_client_a" } }, { "id": "client_b", "service": "supabase", "command": "npx", "args": ["-y", "@supabase/mcp-server-supabase@latest", "--read-only", "--project-ref=REF_B"], "env": { "SUPABASE_ACCESS_TOKEN": "vault:supabase_client_b" } } ] }

Add it to Claude Desktop:

{ "mcpServers": { "janusmcp": {

"command": "/abs/path/janusmcp/go/bin/janusmcp", "args": ["serve"], "env": { "JANUS_CONFIG": "/abs/path/janusmcp/go/config.json" } } } }

For ChatGPT / Gemini / Cursor / Copilot, run HTTP and point them at the URL:

JANUS_TRANSPORT=http JANUS_HTTP_PORT=7332 ./bin/janusmcp serve

→ http://127.0.0.1:7332/mcp

Commands

Run janusmcp help for the full reference. The essentials:

Supported values for install / uninstall: claude-desktop, claude-code, cursor, vscode, gemini, codex, chatgpt, print. Run janusmcp install list (or uninstall list) to see each target and whether it's already configured.

janusmcp install claude-desktop      # one-command setup

janusmcp uninstall claude-desktop # clean removal (restart the client afterwards)

Inside any connected client you also get the control tools janus_list_accounts, janus_use_account, janus_whoami, janus_login, janus_use_profile, and janus_with_account.

Profiles — a whole client's stack at once

A profile groups accounts of the same client across different services. Activating it exposes the tools of *all* its accounts together, and each call is routed to the right upstream:

// config.json

{ "accounts": [ { "id": "supabase_a", "service": "supabase", "transport": "http", "url": "https://mcp.supabase.com/mcp", "auth": "oauth" }, { "id": "github_a", "service": "github", "transport": "http", "url": "https://api.githubcopilot.com/mcp/", "auth": "oauth" } ], "profiles": { "client_a": ["supabase_a", "github_a"] } }

Then in chat: janus_use_profile with { "profile": "client_a" } → Supabase and GitHub tools for Client A are available simultaneously. Colliding tool names across accounts are namespaced ( _ ).

One-shot cross-account calls

janus_with_account runs a single call on another account without changing the active one — e.g. { "account_id": "client_b", "tool": "list_tables" }. Omit tool to list that account's available tools first.

Code-execution mode — context-efficient tools from the terminal

Loading every MCP tool definition into an LLM context is expensive. In code-execution mode an agent (or you) invokes tools on demand from the shell instead — à la "code execution with MCP" — so the context holds only the results it actually asked for:

janusmcp tools                        # compact list for the active account/profile

janusmcp tools client_a # ...or any account/profile explicitly janusmcp schema list_tables # full input schema of ONE tool, only when needed janusmcp call list_tables --args '{"schemas":["public"]}' janusmcp call ping --account azienda_b # cross-account without switching echo '{"sql":"select 1"}' | janusmcp call db_query # JSON args via stdin too janusmcp call ping --json --timeout 30s # stable envelope for agents

call prints the tool's text content to stdout and exits non-zero on a tool error, so it composes with pipes and scripts. Selectors resolve exactly like in the broker: the persisted active account by default, or any account id / profile name; a name that collides across a profile's accounts must be disambiguated with --account. Secrets resolve through the same vault/OAuth stack as serve — nothing extra to configure.

This makes JanusMCP a first-class citizen for CLI-driven agents (Claude Code, Codex, Cursor agents, or any agent with shell access): instead of registering it as an MCP server, just tell the agent that janusmcp tools / schema / call exist. Discovery, schemas and invocation happen on demand, credentials stay in the keychain, and multi-account switching works the same as over MCP. Both modes share the config and the persisted active account, so you can mix them freely.

For repeated calls, janusmcp daemon start launches an authenticated loopback-only broker. tools, schema, and call auto-detect it and reuse its upstream sessions; --direct bypasses it and --daemon requires it. Set JANUS_DAEMON=auto|require|off to choose a default policy.

Key features

| **Dual transport*