1. Conduit
  2. ユースケース
  3. MCP クライアント

開発者向け

まず確認してから動く MCP クライアント

Conduit は Model Context Protocol のサーバーを、ローカル stdio とリモート streamable HTTP の 両方で動かし、OAuth と公式レジストリからのワンクリック導入にも対応しています — そして 1 社のベンダーだけでなく、 選んだどのモデルプロバイダーとも組み合わせて使えます。どのツールも、サーバーが読み取り専用と印を付けていない限り、実行前に確認を求めます。

  • ローカル stdio とリモート streamable HTTP
  • OAuth トークンは OS のキーチェーンへ
  • Windows、macOS、Linux で同じ機能
Conduit が MCP サーバーに接続する仕組み stdio で動くローカルサーバーと、OAuth 付きの streamable HTTP で到達するリモートサーバーは、どちらも Conduit の同意ゲートに入り、そこでツール出力が上限とマスキングを受けたのち、選んだモデルへ渡されます。 ローカルサーバー stdio · child process リモートサーバー streamable HTTP + OAuth Conduit 読み取り専用 → 実行 読み取り専用以外 → 確認 出力は上限とマスキング トークン → OS キーチェーン モデル あなたが選ぶ
ローカルサーバーは restart と backoff を備えた監督付きの child process として動き、リモートサーバーは OAuth 付きの streamable HTTP で接続します。どちらの場合も、モデルに届く前に出力は上限を課され マスキングされ、それを指示として再生させないための防御もあります。

問題

MCP サーバーを見つけた、あるいは自分で作った。ところがそれを動かすはずのクライアントは、1 社のベンダーの モデルとしか話さず、ツールがこれから何をするのかを事前に教えてくれず、Windows は後回しにされていて セットアップ手順がそもそも動きません。 欲しかったのはプロトコルであって、その上に築かれた新しい walled garden ではありません。

クライアントをきちんと比較するには機能一覧だけでは足りません。 Best MCP clients ではそれぞれのトランスポート、同意モデル、 ライセンスを確認しており、Conduit vs Claude Desktop では MCP のセットアップに絞って項目ごとに比較しています。

Conduit が MCP のセットアップに与えるもの

プロトコルを、勘に頼らず使える

ローカルもリモートも同じように振る舞います — 監督され、レート制限され、先に伝えずに動くことは決してありません。

ローカルもリモートも、どちらも監督下に

ローカルサーバーは stdio 経由の child process として動き、restart、backoff、同時実行数の上限、呼び出しごとのタイムアウトを備えます。リモートサーバーは OAuth 付きの streamable HTTP で接続し、トークンは OS のキーチェーンに入り、インターフェースには届きません。古い HTTP+SSE トランスポートは非対応です。

ツールは、サーバーが読み取り専用と印を付けていない限り確認する

ツールが作業を止めずに走るのは、サーバーが読み取り専用と印を付けている場合だけです。それ以外のツールは必ず止まって確認し、このチャットだけか、以後ずっとかを選べます。機微なツールは、以前に何を承認していても必ず確認します。

ツールだけでなく、prompt と resource も

コネクタの保存済み prompt を composer に呼び出せば、宣言された引数が編集可能な形で埋め込まれます。resource を添付すれば、それは次のメッセージにだけ付いていきます。指示を紛れ込ませようとする resource は、黙って従われるのではなく、拒否されたうえで名指しされます。

仕組み

何も繋がっていない状態から、動くツール呼び出しまで

サーバーがどこにあるかによって、入り口は 3 通りあります。

  1. ローカルサーバーを追加する

    コネクタ ページで、起動用のコマンドと引数を指定します。実際のプログラムを指定してください — コネクタは shell を介さず直接起動するので、Windows では npx ではなく npx.cmd となり、cmd /c … によるラップは黙って失敗するのではなく拒否されます。

  2. あるいはレジストリでリモートサーバーを探す

    同じ画面から公式の MCP レジストリを検索し、該当するものをワンクリックで導入できます。サーバーが認証を必要とする場合は、ブラウザで OAuth が開き、トークンは OS のキーチェーンに収まります — インターフェース自体がそれを目にすることはありません。

  3. ツール、prompt、resource を使う

    読み取り専用と印が付いたツール呼び出しは単独で走ります。それ以外は実行前に必ず止まって確認します。prompt を composer に呼び出せば引数はすでに埋まっていますし、resource は送信しようとしているメッセージに添付できます。

MCP なしでも使える

何もつながなくても動くツールがある

Conduit 自体に、サーバーを追加する必要も設定を書く必要もない一握りのツールが組み込まれています。これらは他の MCP ツールと同じ同意ルールに従い、web アクセスはオンにするまでオフのままです。

  • web 検索と web fetch — オンにするまではオフ
  • 電卓、現在時刻、UUID、乱数
  • クリップボードアクセス、ドキュメントの作成と編集

自分でサーバーを作りましたか? MCP サーバーを顧客にデモする方法では、開発者ではない相手の前に置く方法を扱っています。

Conduit の会話の横にあるインスペクターの アクティビティ タブ。そのターンの current_time、calculator、write_markdown_document の呼び出しが、それぞれの所要時間と実行された計算とともに表示され、続いてそのチャットが使ったすべてのツール、書かれたドキュメント、トークン使用量の概要が示されている。

限界

できること、できないこと

できること

  • ローカル MCP サーバーを stdio 経由の監督付き child process として実行し、restart、backoff、同時実行数の上限、呼び出しごとのタイムアウトを備えます
  • OAuth サインインを含め streamable HTTP でリモートサーバーに接続し、トークンは OS のキーチェーンに保持され、インターフェースには一切表示されません
  • 公式の MCP レジストリを検索し、該当するリモートサーバーをワンクリックで導入します
  • コネクタの prompt と resource を composer に呼び出せます — prompt picker は宣言された引数を埋め、resource は次のメッセージにだけ添付されます
  • モデルに届く前にツール出力を上限とマスキングし、それが指示として再生されないよう構造的に防御します
  • Windows、macOS、Linux で同じように動作します — どのプラットフォームでも機能が制限されることはありません

できないこと

  • 非推奨の HTTP+SSE トランスポートには対応しません — サーバーは接続に streamable HTTP を話す必要があります
  • Windows で npx を直接実行しません — コネクタは shell なしで起動するため npx.cmd を使い、cmd /c … によるラップは完全に拒否されます
  • すべてのモデルが tool を呼べるとは保証しません — MCP は選んだどのプロバイダーとも動作しますが、そのモデルが tool calling に対応しているかどうかはモデル次第で、Conduit 次第ではありません
  • 閲覧できるローカルサーバーのパッケージ済みディレクトリは提供していません — ローカルのものはコマンドと引数で追加し、リモートのものはレジストリ検索から導入します
  • まだコード署名済みのインストーラは提供していません — 初回起動時に SmartScreen や Gatekeeper の警告が出ることがあります
  • レジストリ検索と OAuth を完全に非公開には保てません — 検索語は registry.modelcontextprotocol.io へ送られ、OAuth サーバーへの接続時には conduitllm.com から Conduit 自身の client metadata ドキュメントが取得されます

MCP クライアントに関する質問

デスクトップ MCP クライアントとは何ですか
MCP クライアントとは、Model Context Protocol を介してモデルとツールをつなぐアプリケーションのことです — どのサーバーを起動できるか、リモートサーバーにどこから到達するか、ツールを実行する前に何を確認するかを決めます。Conduit もその 1 つです。ローカル stdio とリモート streamable HTTP の両方で MCP を話す、無料でオープンソースのデスクトップアプリで、1 社のベンダーではなく、あなたが選んだどのモデルプロバイダーとも組み合わせて使えます。ほかの MCP クライアントとの比較もご覧ください。
Conduit は MCP サーバーの SSE トランスポートに対応していますか
いいえ — 古い HTTP+SSE トランスポートは意図的に非対応です。Conduit は自分のマシン上のサーバーにはローカル stdio、hosted なサーバーにはリモート streamable HTTP を話します。legacy な SSE エンドポイントしか公開していないサーバーには接続できません。
どの AI モデルでも MCP ツールを使えますか
選んだモデルでなら使えます — Conduit はコネクタを 1 社のプロバイダーに縛りません。変わるのはモデル自体です。すべてのモデルが tool calling に対応しているわけではないので、あるチャットで実際に役立つサーバーがどれかは、Conduit ではなく、そのチャットに選んだモデル次第です。
MCP の OAuth トークンはどこへ行きますか
OS のキーチェーンへ — プロバイダーの API キーと同じ場所です。チャット画面を描画するインターフェースがそのトークンを目にすることは一切ありません。サインインするとそのサーバー自身の OAuth フローが開き、結果を保持するのは Conduit の Rust core です。
Windows で npx が MCP サーバーを起動しないのはなぜですか
Conduit はコネクタを shell を介さず直接起動します。これは意図的なセキュリティ上の防御であり、Windows ではプログラムの実際のファイル名 — npx ではなく npx.cmd — を使うことを意味します。cmd /c … によるラップは、静かに失敗するのではなく、はっきり拒否されます。両方のケースの詳細はドキュメントにまとめてあります。
設定ファイルを編集せずに MCP サーバーを追加できますか
リモートサーバーなら、多くの場合できます。コネクタ ページから公式の MCP レジストリを検索し、該当するものをワンクリックで導入できます。サーバーが必要とする場合は OAuth も自動で処理されます。ローカルサーバーはまだコマンドと引数を自分で入力する必要があり、そのためのパッケージ化されたワンクリック形式はまだありません。

最初のサーバーをつなぐ

無料でオープンソース。自分のキーかローカルモデルを用意し、コネクタ ページからサーバーを追加してください。

まだ release candidate です。インストーラは OS のコード署名を受けていないため、初回起動時に SmartScreen や Gatekeeper の警告が出ることがあります。