Skip to content
ConduitConduit

Supported clients

Conduit is provider-neutral by design. It speaks the standard Model Context Protocol (MCP) end to end — it does not translate tools into any one AI vendor’s format. That means Conduit is the connection fabric for any MCP-capable AI assistant: it gives your AI the access and visibility it needs into your tools, without locking you to a single AI vendor.

Claude Desktop, Claude Code, and Perplexity Computer are the clients we document end-to-end today, but they are examples — not a requirement. Any client that implements the MCP client spec connects the same way.

How any MCP client connects

Section titled “How any MCP client connects”

There are exactly two connection methods, and every MCP-capable client uses one of them:

  1. Native remote MCP — for clients that connect to a remote MCP server by URL directly (e.g. Claude Code’s claude mcp add --transport http).
  2. The mcp-remote bridge — for clients that only connect to local (stdio) MCP servers; a small community tool bridges them to Conduit’s remote endpoint.

Both methods use the same Conduit endpoint (/v1/mcp), and for anything a person signs into, the same OAuth 2.1 sign-in. Unattended agents are the exception — see the paragraph below. Step-by-step: Connecting an AI client.

OAuth is the path for anything that can open a browser. An unattended agent on a server has neither a browser nor a redirect URI, so it connects as a service account one of two ways. Preferred is the device code flow (OAuth 2.0 Device Authorization Grant, RFC 8628): the agent prints a short code and a URL, a person approves it once from any device, and the agent is left with a self-renewing refresh token — no long-lived bearer at rest. A client that pins one Authorization header at process start and cannot run any flow — a platform connector that stores a bearer verbatim, for example — uses a static agent key (Authorization: Bearer cak_…) instead. Both resolve to the same svc:<org-id>:<client-id> identity; see Connect an unattended agent.

Client matrix

Section titled “Client matrix”
Client Connection method Status
Claude Code Native remote (claude mcp add --transport http) Documented — see the connect guide
Claude Desktop Native remote (Custom Connectors, Pro/Max/Team/Enterprise) or mcp-remote bridge (Free) Documented — see the connect guide
Perplexity Computer Native remote (custom connector + OAuth) Documented — see the connect guide
Microsoft Copilot Studio Power Platform custom connector + a service account’s agent key Documented — see Connecting Microsoft Copilot Studio
Cline (VS Code) MCP client — native remote or mcp-remote MCP-spec compatible
Continue (VS Code / JetBrains) MCP client — native remote or mcp-remote MCP-spec compatible
Cursor MCP client — native remote or mcp-remote MCP-spec compatible
Unattended agents (e.g. Hermes) Native remote + a service account — device code (RFC 8628; Hermes sets oauth.flow: device) is the better path, with a static agent key as the fallback for clients that can’t run it Compatible by protocol
Any MCP-spec client Native remote or mcp-remote Compatible by protocol

What the statuses mean:

  • Documented — Conduit has a written, worked connection path for this client (the connect guide).
  • MCP-spec compatible — the client implements the MCP client spec, so it connects through the same standard methods and OAuth flow. Conduit doesn’t special-case any client; if it speaks MCP, it works. Formal per-client connection walkthroughs for these are being added.

What “provider-neutral” means here

Section titled “What “provider-neutral” means here”
  • At the protocol layer — Conduit passes through each vendor’s own MCP tool schemas (JSON-Schema inputSchema); it never reshapes them into a specific AI vendor’s tool-calling format. Any MCP client reads them natively.
  • At the auth layer — connection is standard OAuth 2.1 + PKCE (the MCP authorization spec), not a Claude-specific flow.
  • What this is not — Conduit is not a workflow-automation or chaining tool. It is the connection-and-access layer: it gives your AI assistant secure, permissioned access to the tools you already run, and visibility into how they’re used. The AI does the thinking; Conduit does the connecting.

Clients that don’t speak MCP natively

Section titled “Clients that don’t speak MCP natively”

Some AI platforms do tool-calling but don’t implement the MCP client spec or its OAuth 2.1 + PKCE auth flow. Conduit reaches these through alternative paths:

  • Microsoft Copilot Studio connects through a Power Platform custom connector marked as x-ms-agentic-protocol: mcp-streamable-1.0, authenticated with a Conduit service account’s agent key — a static bearer pasted into the connector — instead of OAuth 2.1. Power Platform never refreshes a stored credential, and an agent key does not need refreshing. The unified /v1/mcp endpoint and the per-vendor /v1/<vendor>/mcp endpoints both work as connector targets. End-to-end walkthrough: Connecting Microsoft Copilot Studio.
  • Apps built directly on a provider’s function-calling API (without an MCP client layer) are not supported out-of-the-box. A per-provider adapter layer is on the roadmap; raise specific needs with your Conduit operator.

Frequently asked questions

Section titled “Frequently asked questions”

Which AI clients work with Conduit?

Section titled “Which AI clients work with Conduit?”

Any MCP-capable client. Conduit speaks the standard Model Context Protocol end to end, so Claude Desktop, Claude Code, Perplexity Computer, Cline, Continue, Cursor, and any other client that implements the MCP client spec connect — there is no per-vendor lock-in.

Do I need a Claude-specific setup to use Conduit?

Section titled “Do I need a Claude-specific setup to use Conduit?”

No. Connection is standard OAuth 2.1 + PKCE (the MCP authorization spec), not a Claude-specific flow, and Conduit passes through each vendor’s own MCP tool schemas unchanged — so any MCP client connects the same way.

How does a client connect to Conduit?

Section titled “How does a client connect to Conduit?”

There are exactly two methods: native remote MCP, for clients that connect to a remote MCP server by URL (like Claude Code’s claude mcp add --transport http), and the mcp-remote bridge, for clients that only speak local stdio MCP. Both use the same Conduit endpoint, and both use the OAuth 2.1 sign-in whenever a person is there to complete it. An unattended agent, which has no browser, instead connects as a service account — by device code, or with a static agent key.

Does Conduit have to add support for a new MCP client before it works?

Section titled “Does Conduit have to add support for a new MCP client before it works?”

No. Because Conduit is MCP-native, client support is a property of the protocol, not a per-vendor integration — a new MCP-capable client works on day one without any change to Conduit.

What about AI tools that don’t speak MCP?

Section titled “What about AI tools that don’t speak MCP?”

Some platforms do tool-calling without native MCP — for example, an app built directly on a provider’s function-calling API. Support for those is a demand-driven roadmap item, an additive per-provider adapter layer, not shipped today. Raise specific needs with your Conduit operator.

Section titled “Related”