Support

Open-Source Chat Clients Setup

Connect Tempreon to open-source chat clients — Open WebUI, LibreChat, Cherry Studio, Jan, AnythingLLM, Msty, and Goose — with or without built-in OAuth.

Ready to connect? Your Bridges page walks you through it step by step.

Open your Bridges page

Overview

The open-source ecosystem has produced a wave of capable chat clients — Open WebUI, LibreChat, Cherry Studio, Jan, AnythingLLM, Msty, and Goose among them. They run whatever model you point them at (local via Ollama or llama.cpp, or any hosted API), and most now speak MCP. Connecting Tempreon gives all of them the same thing: your AI loads your Core Imprint, searches your Knowledge Vault, and remembers what it learns — across every tool.

Every client on this page uses the same server URL, also shown in your Bridges dashboard:

https://api.tempreon.com/functions/v1/tempreon-mcp/mcp

The mcp-remote proxy. Clients without a built-in OAuth flow use mcp-remote — a local stdio bridge that opens the browser OAuth for them and forwards tool calls to Tempreon. Wherever a client below needs it, this is the command (requires Node 20+):

npx -y mcp-remote https://api.tempreon.com/functions/v1/tempreon-mcp/mcp

Prerequisites

  • A Tempreon account with at least one available Bridge slot
  • One of the clients below, updated to a current build
  • For the mcp-remote clients: Node.js 20 or later installed

Clients with native OAuth — connect directly

Open WebUI

Self-hosted, browser-based, works with any model backend (Ollama, OpenAI-compatible APIs, OpenRouter). Native MCP support — Streamable HTTP only — arrived in v0.6.31.

  1. Open Admin Panel → Settings → External Tools
  2. Add a new tool with the type MCP (Streamable HTTP)
  3. Paste the server URL and set authentication to OAuth 2.1
  4. Each user completes the browser OAuth individually the first time they use it

Two gotchas: if you run Open WebUI in Docker, set a fixed WEBUI_SECRET_KEY — without it, stored OAuth tokens break every time the container restarts. And set your model's Function Calling setting to Native, or tools won't be called reliably.

LibreChat

Self-hosted chat platform for any model provider. Add Tempreon to librechat.yaml and restart:

mcpServers:
  tempreon:
    type: streamable-http
    url: https://api.tempreon.com/functions/v1/tempreon-mcp/mcp

When no credentials are configured, dynamic client registration is the default — exactly what Tempreon expects. Users trigger the browser OAuth from the chat UI the first time they use the server.

Goose

Block's open-source AI agent — desktop and CLI, any model provider.

  • One-click (Desktop): Add to Goose — with Goose Desktop installed, this opens the add-extension dialog pre-filled
  • Desktop (manual): Settings → Extensions → Add custom extension → type Streamable HTTP → name + URL
  • CLI, one session: goose session --with-streamable-http-extension "https://api.tempreon.com/functions/v1/tempreon-mcp/mcp"
  • CLI, persistent: add to config.yaml:
extensions:
  tempreon:
    enabled: true
    type: streamable_http
    name: Tempreon
    uri: https://api.tempreon.com/functions/v1/tempreon-mcp/mcp
    timeout: 300

Goose starts the browser OAuth automatically when the server asks for it. On current builds it may re-prompt for authorization each session — approve and continue.

Msty

Desktop app for local and hosted models; its tool system is called the Toolbox, available on the free desktop app.

  1. Open the Toolbox and add a tool
  2. Choose HTTP and paste the server URL
  3. Pick OAuth authentication — the browser flow opens when the connection is first used

Msty supports Streamable HTTP only; SSE servers aren't supported. Tempreon is Streamable HTTP, so it connects directly.

Cherry Studio

Desktop app (Windows, macOS, Linux) with 20+ model providers, including Ollama, OpenRouter, Qwen, and DeepSeek.

  1. Open Settings → MCP Servers → + Add Server
  2. Set the type to streamableHttp and paste the server URL
  3. Save, then enable Tempreon via the MCP tools icon under the chat input

Cherry Studio ships an OAuth flow, but it has been uneven across releases — test it, and if authorization fails, switch to a stdio entry using the mcp-remote command from the callout above. Keep the app updated; recent releases also carry security fixes.

Clients that use the mcp-remote proxy

Jan

Free, open-source desktop app running local models via llama.cpp, plus cloud providers. Current builds handle OAuth for remote MCP servers themselves — Jan reads the server's metadata, registers itself dynamically, and completes the authorization-code flow with PKCE — so Tempreon connects directly, with no proxy and no credentials to paste.

  1. Open Settings → MCP Servers and toggle the MCP host on
  2. Click + Add MCP Server
  3. Add Tempreon as a remote HTTP server with this URL:
https://api.tempreon.com/functions/v1/tempreon-mcp/mcp

Your browser opens for the Tempreon consent screen on first use. On an older build that offers no remote option, fall back to a stdio entry — Command: npx, Args: -y, mcp-remote, and the URL above — which does the same OAuth outside the app.

AnythingLLM

Desktop and Docker workspace app for any model. MCP servers are configured in anythingllm_mcp_servers.json in the storage plugins/ directory:

{
  "mcpServers": {
    "tempreon": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://api.tempreon.com/functions/v1/tempreon-mcp/mcp"]
    }
  }
}

If you go direct instead, AnythingLLM's HTTP type keyword is "type": "streamable" (omit it and SSE is assumed) — but its authentication is headers-only with no OAuth, so for Tempreon use the mcp-remote stdio entry above. Refresh the server list on the Agent Skills page, and invoke tools via @agent.

Two more you might be using

  • Continue.dev still works locally with type: streamable-http in ~/.continue/config.yaml and a native OAuth browser prompt, but it is no longer maintained following its acquisition.
  • Former Roo Code users: Roo shut down in May 2026 — its community fork continues with the same config format, and needs the mcp-remote proxy.

Troubleshooting

The connection fails immediately. Confirm the URL ends in /mcp with no trailing slash: https://api.tempreon.com/functions/v1/tempreon-mcp/mcp.

npx: command not found, or mcp-remote won't start. The proxy needs Node.js 20 or later — install or update Node, then retry.

Tools connect but the model never calls them. Check the model side: it needs tool-calling support, and in Open WebUI the model's Function Calling setting must be Native. Smaller local models can also struggle with large tool lists.

OAuth tokens stop working after a restart. In Dockerized Open WebUI, set a fixed WEBUI_SECRET_KEY. Elsewhere, remove and re-add the server to run a fresh OAuth flow.

Also connect: LM Studio · Connect Any MCP Client · Claude Desktop

Try saying...

  • "Start my session." — triggers session_start to load your Core Imprint
  • "What do you know about me from Tempreon?" — a quick end-to-end test
  • "Remember that [insight] for next time." — proves the write path works from your client

Frequently asked questions

How does authorizing Tempreon work across these open-source clients?
It depends on whether the client has its own OAuth flow. Clients with native OAuth (Open WebUI, LibreChat, Goose, Msty, Cherry Studio, and now Jan) connect directly and open the browser consent screen themselves. AnythingLLM has no OAuth flow, so it uses mcp-remote, a local stdio bridge that opens the browser OAuth and forwards tool calls to Tempreon, and it needs Node.js 20 or later.
Where do I add the Tempreon server in these clients?
Each client keeps its MCP settings in a different place, so follow that client's section on this page. Some use an in-app panel, like Open WebUI under Admin Panel then Settings then External Tools, Msty in its Toolbox, and Goose under Settings then Extensions. Others use a config file, such as LibreChat's librechat.yaml or AnythingLLM's anythingllm_mcp_servers.json in the storage plugins directory.
Tempreon connects but my model never actually calls its tools. How do I fix it?
This is usually the model side rather than the connection. The model needs tool-calling support, and in Open WebUI its Function Calling setting must be set to Native or tools will not be called reliably. Smaller local models can also struggle with large tool lists, so moving to a model with solid tool-calling support often resolves it.