For developers
Conduit runs Model Context Protocol servers over local stdio and remote streamable HTTP, with OAuth and one-click installs from the official registry — and it works with whichever model provider you pick, not just one vendor's. A tool asks before it runs unless its server marks it read-only.
The problem
You found or built an MCP server. The client you're supposed to run it in only talks to one vendor's models, can't tell you what a tool is about to do before it does it, and treats Windows as an afterthought where the setup instructions just don't work. You wanted the protocol, not a new walled garden built on top of it.
Comparing clients properly takes more than a features list — Best MCP clients checks the transports, consent model, and licence of each one, and Conduit vs Claude Desktop goes row by row on MCP setup specifically.
What Conduit gives an MCP setup
Local and remote servers behave the same way: supervised, rate-limited, and never allowed to act without telling you first.
Local servers run as child processes over stdio, with restart and backoff, a concurrency limit, and a per-call timeout. Remote ones connect over streamable HTTP with OAuth; tokens land in the OS keychain and never reach the interface. The older HTTP+SSE transport isn't supported.
A tool runs without interrupting you only when its server marks it read-only. Every other tool stops and asks, and you can approve it for this chat or always. Sensitive tools always ask, no matter what you've approved before.
Pull a connector's saved prompt into the composer and its declared arguments fill in for you to edit. Attach a resource and it rides along with your next message only. A resource that tries to slip in instructions is refused and named, not silently followed.
How it works
Three ways in, depending on where the server lives.
On the Connectors page, give the command and arguments that start it. Point at the real program — connectors start directly, never through a shell — so on Windows that means npx.cmd, not npx, and a cmd /c … wrapper is refused rather than silently failing.
From the same screen, search the official MCP registry and install a match in one click. If the server needs authentication, OAuth opens in your browser and the token lands in your OS keychain — the interface itself never sees it.
Tools marked read-only run on their own; every other tool stops and asks before it runs. Pull a prompt into the composer and its arguments are already filled in, or attach a resource to the message you're about to send.
No MCP required
A handful of tools ship in Conduit itself, with no server to add and no configuration to write. They follow the same consent rules as any MCP tool, and web access stays off until you turn it on.
Built the server yourself? How to demo an MCP server to a customer covers putting it in front of someone who isn't a developer.
Limits
npx directly on Windows — connectors start without a shell, so use npx.cmd, and a cmd /c … wrapper is refused outrightregistry.modelcontextprotocol.io, and connecting an OAuth server fetches Conduit's own client metadata document from conduitllm.comAn MCP client is the application that connects a model to your tools over the Model Context Protocol — it decides which servers it can start, where a remote one is reached from, and what to ask you before a tool runs. Conduit is one: a free, open-source desktop app that speaks MCP over local stdio and remote streamable HTTP, and works with whichever model provider you pick rather than one vendor's. See how it compares to other MCP clients.
No — the older HTTP+SSE transport is deliberately not supported. Conduit speaks local stdio for servers on your own machine and remote streamable HTTP for hosted ones; a server that only publishes the legacy SSE endpoint won't connect.
With the model you choose, yes — Conduit doesn't restrict connectors to one provider. What varies is the model itself: not every model supports tool calling, so which servers are actually useful in a given chat depends on the model you pick for it, not on Conduit.
Into the OS keychain, the same place your provider API keys live. The interface that renders your chat never sees the token — signing in opens the server's own OAuth flow, and Conduit's Rust core holds the result.
Conduit starts connectors directly rather than through a shell, which is a deliberate security guard — and on Windows that means using the program's real filename: npx.cmd, not npx. A cmd /c … wrapper is refused outright rather than failing quietly. The docs cover both cases in full.
For a remote one, often yes: search the official MCP registry from the Connectors page and install a match in one click, with OAuth handled automatically if the server needs it. A local server still needs a command and its arguments typed in — there's no packaged one-click format for those yet.
Related
Your own API keys for every provider, in the same app that runs your MCP servers.
Bring your own key For air-gapped setupsOllama or LM Studio underneath, MCP tools on top, and no internet required for either.
Run models locally For MCP server vendorsDemo your server inside a client with your name on it, not a competitor's onboarding funnel.
White-label ConduitMore on setup and troubleshooting — including the Windows command-naming rules above — is in the documentation.
Free and open source. Bring your own key or a local model, then add a server from the Connectors page.
A release candidate: installers aren't OS code-signed yet, so expect a SmartScreen or Gatekeeper prompt on first launch.