症状：MCP Serverを追加したのにツールが表示されない、または接続後に動作が不安定になる。 最速解決：読み取り専用のMCP Serverを1台だけ接続し、ツール発見と権限経路を確認してから、書き込み機能とクラウド運用へ進んでください。

この手順は、DeepSeek Harnessを使ってコード検索、データベース照会、ブラウザー操作、社内ツール呼び出しを行う開発者向けです。継続実行やチーム共有が目的なら、個人Macの一時的なターミナルではなく、DeepSeek Harness、MCP Server、依存プロセスを再現可能な環境へ固定してください。

最終更新：2026年8月18日。DeepSeek Harnessの公式リポジトリ、MCP関連資料、現行のMCP Inspector資料を確認しています。DeepSeek HarnessはDeveloper Preview段階のため、設定キー、設定ファイルの場所、利用できるトランスポートは、作業当日に公式リポジトリのMCP関連資料で再確認してください。

事前準備：MCPツールの危険度を分ける

最初にMCPツールを次の3種類へ分類します。

  • 読み取り専用：コード検索、スキーマ確認、ログ取得、メタデータ照会。
  • 制御付き書き込み：チケット更新、ブランチ作成、データ登録など、対象と承認を限定できる操作。
  • 実行系：シェル、デプロイ、削除、外部サービスへの送信など、失敗時の影響が大きい操作。
初回接続では読み取り専用だけを許可します。書き込みツールを先に有効にすると、接続不良、権限不良、ツール自体の副作用が同時に発生し、原因を特定できなくなります。

成功条件も先に固定してください。例えば「指定したリポジトリから特定の関数定義を取得し、ファイル名と行番号を含む結果を保存する」というタスクなら、成功の証拠は、ツール名、入力引数、返却結果、生成された成果物の4点です。

MCPはDeepSeekのモデルAPIそのものではありません。モデルAPIは推論を提供し、MCP Serverは外部ツールやリソースとの接続を提供します。この2つを同じ設定項目として扱うと、APIキーの問題をMCP接続エラーと誤認しやすくなります。

判断条件：次に進むか基本構成へ戻すか

以下を、初回接続後と遠隔環境への移行前に確認してください。条件を満たさない項目があれば、次の機能を追加せず、MCP設定を外した基本構成へ戻します。

  • [ ] MCP Serverを1台だけ起動できる。
  • [ ] 起動ディレクトリ、実行ユーザー、依存ランタイムを記録している。
  • [ ] initializeが完了し、Server情報と機能一覧を取得できる。
  • [ ] tools/listで読み取り専用ツールが表示される。
  • [ ] 副作用のないtools/callを1回実行し、結果を保存できる。
  • [ ] ツールの必須引数、型、空結果、タイムアウトを確認している。
  • [ ] 秘密情報が設定ファイル、プロンプト、標準出力、ログへ出ていない。
  • [ ] 書き込みが必要な場合、対象、承認者、ロールバック方法を決めている。
  • [ ] SSH接続を切断しても、必要なプロセスが意図した方式で継続する。
  • [ ] MCP設定を削除した状態で、DeepSeek Harnessが基本機能へ戻る。
**判定ルール**
  • すべて確認できた場合は、制御付き書き込みツールを限定的に追加します。
  • 読み取りは成功するが、プロセス復旧や資格情報の管理を確認できない場合は、検証環境だけで継続します。
  • initializeまたはtools/listが失敗する場合は、書き込み機能を追加せず、Server、通信、登録設定を切り分けます。
  • 基本構成へ戻せない場合は、遠隔環境への移行を中止し、まず起動責任と設定の読み込み先を見直します。
  • 複数Serverが異なる秘密情報、依存ランタイム、信頼境界を持つ場合は、同じ実行環境へまとめず、別プロセスまたは別環境へ分けます。
この条件分岐を先に作ると、「接続できたから本番運用へ進む」という曖昧な判断を避けられます。

初回接続：単一MCP Serverで経路を固定する

DeepSeek HarnessのDeveloper Previewでは、公式に確認できる現行の設定方法をそのまま使い、他のAIクライアントの設定例を流用しないでください。コミュニティ製の設定例は、同じMCP形式を使っていても、設定ファイルの場所やキー名が異なる可能性があります。

実施順は次のとおりです。

  1. バージョンと起動場所を記録します。
DeepSeek Harness、MCP Server、ランタイムのバージョン、起動ディレクトリ、実行ユーザーをメモします。相対パスを使うMCP Serverでは、起動ディレクトリが変わるだけで接続に失敗します。
  1. MCP Serverを1台だけ登録します。
ローカル接続ならstdio、リモート接続なら公式資料で確認できるHTTP系の方式を選びます。MCP Inspectorの公式資料では、stdio、SSE、Streamable HTTPの設定例が分けて示されていますが、DeepSeek Harnessが同じ方式を同じ設定キーで受け付けるとは限りません。
  1. プロセス起動を確認します。
stdioの場合は、標準出力へ診断メッセージを出さないことが重要です。JSON-RPCの通信に不要な文字列が混ざると、プロセス自体は起動していても初期化に失敗します。HTTP系の場合は、公開インターネットへ直接バインドせず、まずループバックまたは許可済みの内部経路で確認します。
  1. initializeの完了を確認します。
ここではまだ実際のツールを使いません。プロトコルバージョン、Server情報、機能一覧が返ることを確認し、失敗時のログを保存します。
  1. tools/listを確認します。
ツール名と入力スキーマが返るかを確認します。MCP InspectorのCLIは、接続確認にinitialize、ツール一覧にtools/list、実行にtools/callを使う設計です。[MCP Inspectorの接続設定例](https://github.com/modelcontextprotocol/inspector/blob/main/docs/mcp-server-configuration.md)を使えば、Harnessへ登録する前にServer単体の状態を切り分けられます。
  1. 最小タスクを1回だけ実行します。
副作用のない検索または参照を行い、入力と結果を保存します。複数のMCP Server、複数のAI Agent、書き込み権限を同時に追加してはいけません。

接続が失敗したら、最初にMCP設定を削除した基本構成へ戻します。基本構成でHarnessが起動するなら、モデルAPIではなくMCPの登録、プロセス、トランスポートのいずれかに問題があります。

ツール発見：表示されない原因を順番に分ける

MCP Serverが起動しているのにDeepSeek Harnessへツールが出ない場合、次の順番で確認します。

  • プロセスエラー：依存パッケージ不足、実行権限不足、作業ディレクトリ違い、環境変数不足。
  • 通信エラー：stdioの出力混入、HTTP URL違い、認証ヘッダー不足、セッション切断。
  • 登録エラー：設定ファイルの読み込み先違い、Server名の重複、現在のHarness版で未対応の設定キー。
  • スキーマエラー：tools/listには表示されるが、必須引数や型の解釈に失敗する状態。
ツールが表示されても、すぐに書き込み操作へ進まないでください。まず無害な問い合わせを実行し、必須パラメーター、空の結果、タイムアウト、エラーメッセージを確認します。MCP InspectorのCLIからtools/callを実行できるため、[Inspector CLIのメソッド一覧](https://github.com/modelcontextprotocol/inspector/blob/main/clients/cli/README.md)を参照し、Server単体の返却形式を確定させてください。

接続確認の記録には、次の情報を残します。

  • 実行日時と各コンポーネントのバージョン。
  • 起動ディレクトリと実行ユーザー。
  • Serverの起動ログと、資格情報を伏せた接続ログ。
  • 使用したツール名、入力スキーマ、結果の保存先。
  • 失敗した場合のエラー分類と、MCP設定を除去した状態での復旧結果。
公式Inspectorの現行資料では、Node.js 22.7.5以上が要件として示されています。また、Inspectorの既定UIポートは6274、プロキシ側は6277です。これらはDeepSeek Harnessの要件や既定値ではないため、Harnessの動作条件として読み替えないでください。[Inspector公式README](https://github.com/modelcontextprotocol/inspector#security-considerations)

権限設計：資格情報と書き込み範囲を分離する

資格情報は、次の3層を混ぜないことが重要です。

  • 環境変数：実行時に注入する秘密情報。
  • 設定ファイル：Serverのコマンド、引数、作業ディレクトリ、非秘密の接続情報。
  • 承認ルール：どのツールを、どの対象へ、どの条件で実行できるか。
stdio接続では、MCPの認証仕様上、資格情報を環境から取得する設計が推奨されています。HTTP接続では、認証サーバーやアクセストークンなど、トランスポート層の認証を別に扱います。[MCP公式認証仕様](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)

データベース書き込みやファイル変更を許可する場合は、対象の限定、承認者、変更前のバックアップ、ロールバック方法を決めてください。外部入力をそのままツール引数に渡すAI Agentでは、入力の検証と実行結果の確認を必須にします。

実行権限は、MCP Server単位だけでなく、ツール単位でも確認します。例えばデータベースの参照権限と更新権限を同じ資格情報へまとめると、プロンプトの誤解釈や入力検証の不備が、そのまま変更操作へつながります。

FAQ：接続方式と遠隔運用

MCP Serverの接続方式

DeepSeek Harnessで利用できる接続方式は、Developer Previewの更新により変わる可能性があります。ローカルのstdio接続と、URLを使うHTTP系接続を候補にしつつ、実際に使える設定キーは当日の公式資料で確定させます。SSEやStreamable HTTPの例を、Harnessの設定へそのまま貼り付ける運用は避けてください。

ツールが表示されない場合

Server単体でinitializeとtools/listが成功しているかを先に確認します。そこで失敗するならServerまたは通信の問題です。Server単体では成功するのにHarnessだけ表示されない場合は、設定ファイルの読み込み先、実行ユーザー、作業ディレクトリ、登録名の重複を比較します。

リモートMacの秘密情報

リモートMacでは、秘密情報をログインシェルの手入力に頼らず、専用の実行ユーザーへ安全に注入します。SSH接続を切った後も同じ参照方法で起動できるかを確認し、シェル履歴、プロセス一覧、バックアップ、ログへ秘密情報が残っていないかを点検します。

複数Serverの配置

検証中は1台ずつ分けるのが基本です。継続運用で同居させる場合も、依存ランタイム、再起動単位、資格情報、ログ、ネットワーク許可をServerごとに追跡できる構成にします。信頼境界が違うServerの同居は、障害時の影響範囲を広げます。

遠隔運用：クラウドMacでプロセス責任を固定する

クラウドMacへ移行する前に、誰が何を起動し、監視し、再起動するかを決めます。最低限、DeepSeek Harness、MCP Server、データベースやブラウザーなどの依存プロセスを別々に一覧化してください。

実施する確認は次の5点です。

  1. SSHを切断しても、必要なプロセスが意図した監視方式で継続すること。
  2. 再起動後も作業ディレクトリ、実行ユーザー、環境変数が変わらないこと。
  3. MCP ServerのログがHarnessのログと混ざらず、時刻を比較できること。
  4. HTTP接続を使う場合、MCPポートを無制限に公開せず、認証、許可元、TLS、ファイアウォールを設定すること。
  5. MCP設定を削除した状態で、DeepSeek Harnessが基本機能へ戻れること。
クラウドMacを選ぶときは、単にCPUやメモリの大きさを見るのではなく、再起動、アクセス権、作業ディレクトリ、ログ回収を自分の運用手順で再現できるかを確認してください。必要な環境候補は[MACGPUのクラウドMac案内](https://macgpu.com/ja/index.html)から確認でき、Macの用途や構成を比較する場合は[Macレンタル構成の案内](https://macgpu.com/ja/m4-chumon.html)も参照できます。

受け入れ試験：エンドツーエンドで判定する

最後は、次の基準タスクを1本作ります。

「MCP Serverから対象データを検索し、結果を要約し、書き込みが必要な場合だけ承認を求め、承認後に限定された対象へ変更を行い、変更結果を成果物として保存する」という流れです。

判定は3段階に分けます。

  • 合格：ツール発見、引数検証、結果処理、承認、成果物保存、再起動後の復旧がすべて確認できる。
  • 条件付き合格：読み取りまでは成功するが、書き込み承認または再起動復旧が未確認。検証環境限定で使用する。
  • 不合格：ツール一覧が不安定、権限が過剰、ログから原因を追えない、MCP設定を外しても基本構成へ戻れない。
DeepSeek Harnessは開発者向けプレビューであるため、更新時には同じ基準タスクを再実行します。設定キー、トランスポート、権限モデル、ツール登録の挙動が変わった場合は、過去の成功記録をそのまま信頼せず、最小構成から再検証してください。

個人Macの一時セッションは、短時間の読み取り確認には向いていますが、接続断後のプロセス状態が不明確で、秘密情報の注入方法も担当者依存になりやすく、チーム共有時にはログと再起動責任が曖昧になります。継続稼働や交代運用まで考えるなら、MCP設定を隔離でき、プロセス復旧を確認できるクラウドMacの方が、現在の運用より判断しやすい構成になります。

まず単一MCP Serverのローカル検証を終え、その基準タスクを持ったままMACGPUの遠隔Mac環境で切断、再起動、成果物保存まで確認してください。すべてのMCP Serverとの互換性を先に約束するのではなく、使うServerを1台ずつ受け入れる運用にすると、DeepSeek Harnessの更新にも回退可能な形で対応できます。