--- title: "Docker MCP Gatewayの使い方｜docker mcp gateway runの主要オプションと認証・インターセプター【2026年10月】" url: "https://www.issoh.co.jp/tech/details/7981/" published: 2025-08-01 updated: 2026-10-31 categories: ["AIエージェント・MCP"] publisher: "株式会社一創" --- # Docker MCP Gatewayの使い方｜docker mcp gateway runの主要オプションと認証・インターセプター【2026年10月】 Docker MCP Gatewayは、MCP（Model Context Protocol）サーバーをDockerコンテナとして起動し、AIクライアントからの接続口を1つにまとめるDocker公式のオープンソースのプロキシです。中身は `docker mcp` CLIプラグインの `docker mcp gateway run` で、Docker DesktopのMCP Toolkitを有効にすると裏で自動的に動きます。2026年10月26日公開のv0.44.3ではサーバーの指定方法がプロファイル方式に切り替わっており、以前の解説にある `docker mcp server enable` の手順は通りません。この記事では、v0.44.3の公式イメージを手元で動かして確かめた挙動をもとに、起動方法、主要オプションの既定値、HTTP接続の認証、インターセプター、他社の「MCPゲートウェイ」との違いを順に説明します。 ## まとめ：Docker MCP Gatewayの要点（v0.44.3時点） - **正体**：GitHubの `docker/mcp-gateway`（MITライセンス）。2026年10月時点の最新は2026年10月26日公開のv0.44.3（GitHub上はPre-release表示）。Docker Desktopを使っている場合はMCP Toolkitが自動で起動するため、手で動かす必要はない。 - **サーバーの指定**：v0.44.3はプロファイル方式が常時有効。`--profile` を省くと `default` プロファイルを使い、`--servers` を付けるとカタログ直指定の従来方式になる。両方は同時に指定できない。 - **HTTP接続**：`--transport=sse|streaming` ではBearerトークンが必須（未設定なら起動ごとに50文字のトークンを自動生成）。`--host` を付けないと全インターフェースで待ち受けるので、手元だけで使うなら `--host 127.0.0.1` を付ける。 - **安全の既定値**：署名検証・シークレット遮断・呼び出しログは既定で有効。外向き通信は既定では遮断されないため、必要なら `--block-network` を付ける。 - **注意点**：beforeインターセプターはstreaming/sse接続で失敗する既知の不具合（Issue #358・未解決）があり、v0.44.3でも再現した。IBM・Microsoft・Cloudflareの「MCPゲートウェイ」は別製品。 ## Docker MCP Gatewayとは：MCPサーバーをコンテナで束ねるプロキシ [Docker公式ドキュメントのMCP Gatewayのページ](https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/)は、Gatewayを「クライアントとサーバーの間に立つ集中型のプロキシで、設定・認証情報・アクセス制御を管理する」ものと説明しています。Gatewayが無い構成ではAIアプリごとに各MCPサーバーの接続を設定しますが、Gatewayを使うとアプリはGatewayだけに接続し、サーバーの起動・振り分け・認証はGatewayが受け持ちます。AIエージェント同士の通信を仲介するメッセージブローカーではありません。MCPの基本は[MCP（Model Context Protocol）とは？仕組み・APIとの違い・MCPサーバーの作り方](/tech/details/5736/)で解説しています。 ### ツール呼び出しが届くまでの流れ AIアプリがツールを呼ぶと、Gatewayはそのツールを持つサーバーを特定し、まだ動いていなければDockerコンテナとして起動します。続いて必要な認証情報を注入し、制限をかけたうえで要求を転送し、結果をアプリへ返します。v0.44.3の公式イメージで `duckduckgo` サーバーを指定して起動したところ、ログには `--security-opt no-new-privileges --cpus 1 --memory 2Gb --network bridge` を付けたコンテナ起動が記録され、サーバーのイメージはタグではなくダイジェスト（`mcp/duckduckgo@sha256:…`）で固定されていました。2026年10月31日にColima上のDocker Engine 29.5.2（amd64）で各1回測定した初期化時間は、初回約18秒、2回目約5秒でした。署名検証とツール一覧取得を含む、この環境での観測値です。 ### MCP Toolkit・MCP Catalog・Gatewayの役割分担 DockerのMCP関連は3つの部品に分かれます。**MCP Catalog**は検証済みサーバーのイメージを集めたカタログで、[公式の概要ページ](https://docs.docker.com/ai/mcp-catalog-and-toolkit/)の表記は「300+ verified servers」です。**MCP Toolkit**はDocker Desktopの画面とCLIで、プロファイル作成やクライアント接続を扱います。**MCP Gateway**はその裏でサーバーを実際に起動・集約・保護する実行部分です。Toolkitの有効化やプロファイル作成、Claude・Cursorへの接続手順は[Docker MCP Toolkitの使い方｜プロファイル作成とClaude・Cursor接続、docker mcpコマンド](/tech/details/7218/)にまとめ、この記事はGateway本体の起動方法と設定に絞ります。 なお、公式ドキュメントのMCP Gatewayのページ冒頭には「Docker AI Governanceの一部としてのMCP Gatewayは招待制の機能」という注記があります。これは組織向けのガバナンス製品の一機能を指すもので、GitHubで公開されているOSS版の `docker mcp gateway run` は誰でも使えます。 ## docker mcp gateway runの起動方法 起動経路はDocker Desktop経由、CLIプラグインの単体導入、公式イメージの3通りです。手元でAIアプリから試すだけならDocker Desktop、Linuxサーバーやほかのコンテナから使うなら公式イメージが手間がかかりません。 ### Docker DesktopとCLIプラグインの単体導入 Docker DesktopでMCP Toolkitを有効にしていれば、`docker mcp` プラグインは同梱済みで、Gatewayは自動で起動します。Docker Engineだけの環境では、[GitHubのリリースページ](https://github.com/docker/mcp-gateway/releases)からOSに合うバイナリ（v0.44.3はLinux・macOS・Windowsのamd64/arm64の6種類）を取得します。Linux・macOSでは `~/.docker/cli-plugins/docker-mcp` に置いて実行権限を付けます。Windowsでは `%USERPROFILE%\.docker\cli-plugins` に実行ファイルを配置します。ただし、Docker Desktopの動いていないmacOSでは `docker mcp` の各サブコマンドが「Docker Desktop is not running」で止まります（Docker MCP Toolkitの記事で実測）。Docker Desktopを入れていないMacでは、次の節の公式イメージを使ってください。以下のコマンド例はLinux amd64向けです。 ``` tar -xzf docker-mcp-linux-amd64.tar.gz mkdir -p ~/.docker/cli-plugins mv docker-mcp ~/.docker/cli-plugins/docker-mcp chmod +x ~/.docker/cli-plugins/docker-mcp docker mcp version ``` ### 公式イメージdocker/mcp-gatewayのCompose起動構成 公式イメージ `docker/mcp-gateway` は、エントリーポイントが `/docker-mcp gateway run` で、環境変数 `DOCKER_MCP_IN_CONTAINER=1` を持っています。Dockerソケットを渡せばDocker Desktop無しで動き、ほかのコンテナのエージェントからHTTPで呼べます。次の構成は、v0.44.3でトークン無しの接続が401、トークン付きが200になることを確かめたものです。2026年10月31日に確認した時点で `latest` タグはv0.44.3ではなく2026年7月23日作成の古いビルドを指していたので、版を固定してください。 ``` services: gateway: image: docker/mcp-gateway:v0.44.3 command: - --servers=duckduckgo - --transport=streaming - --port=8811 environment: - MCP_GATEWAY_AUTH_TOKEN=${MCP_GATEWAY_AUTH_TOKEN:?MCP_GATEWAY_AUTH_TOKENを設定してください} ports: - "127.0.0.1:8811:8811" volumes: - /var/run/docker.sock:/var/run/docker.sock ``` Dockerソケットを渡すことは、Gatewayにホストの全コンテナを操作する権限を渡すことと同じです。共用サーバーで動かす場合は、このコンテナを動かせる人を絞ってください。 ## プロファイル方式と–servers指定の違い v0.44.3のソースでは、プロファイル機能の判定関数（`readProfilesFeature`）が常に `true` を返します。そのため `docker mcp server enable` などは「Obsolete」の隠しコマンドに置き換わり、`docker mcp profile server add` を使うよう案内されます。旧版で使われていた `docker mcp server enable brave duckduckgo` の手順は、現行版では動きません。 `docker mcp gateway run` がどのサーバーを公開するかは、次の2つの方式で決まります。 | 方式 | 指定方法 | 向いている場面 | | -------- | -------------------------------------- | ---------------------- | | プロファイル方式 | `--profile 名前`（省略時は `default`） | Docker Desktopと同じ設定を使う | | 従来方式 | `--servers`・`--catalog`・`--secrets` など | コンテナ・CIで構成を引数に書く | 2つの方式は排他です。`--servers=duckduckgo --profile=x` を同時に渡すと、v0.44.3は「cannot use –profile with –servers, –enable-all-servers, –catalog, …」で起動を止めました。また、`--servers` でサーバーを明示すると、エージェントが会話中にサーバーを探して追加する動的ツール（`mcp-find`・`mcp-add` など）が無効になります。ソースのコメントには「サーバーを明示するユーザーは手動の運用をしているため」とあります。動的ツールの使い方は、前述の「Docker MCP Toolkitの使い方」で解説しています。 ``` # プロファイル方式（Docker Desktopで作ったプロファイルを使う） docker mcp gateway run --profile dev-tools # 従来方式（カタログのサーバー名を直接指定する） docker mcp gateway run --servers=duckduckgo --tools=duckduckgo:search ``` ## docker mcp gateway runの主要オプションと既定値 オプションの一覧は[公式CLIリファレンス](https://docs.docker.com/reference/cli/docker/mcp/gateway/run/)にありますが、2026年10月31日時点の表にはv0.43.1（2026年6月25日）で入った `--host` と `--allow-unauthenticated`、v0.44.1で入った `--preserve-tool-schema-dialect` が載っていません。`--verify-signatures` の既定値も空欄ですが、v0.44.3の[gateway.goのソース](https://github.com/docker/mcp-gateway/blob/v0.44.3/cmd/docker-mcp/commands/gateway.go)ではホスト上・コンテナ内のどちらでも `true` です。次の表はソースを正として整理しました。 | オプション | 既定値 | 役割 | | ------------------------- | ---------------------------------------------- | ------------------- | | `--transport` | stdio | stdio・sse・streaming | | `--port` | 8811（HTTP時） | 待受ポート。stdioと併用不可 | | `--host` | 空＝全インターフェース | HTTP待受のバインド先 | | `--allow-unauthenticated` | false | HTTP接続の認証を外す | | `--profile` | default | 使うプロファイル | | `--servers` | なし | カタログのサーバー名を直接指定 | | `--tools` | なし | 公開するツールを絞る | | `--secrets`（ホスト） | docker-desktop | シークレットの参照先 | | `--secrets`（コンテナ） | `docker-desktop:/run/secrets/mcp_secret:/.env` | シークレットの参照先（.envも可） | | `--verify-signatures` | true | mcp/名前空間のイメージ署名を検証 | | `--block-secrets` | true | 引数と応答の秘密情報を遮断 | | `--log-calls` | true | ツール呼び出しを記録 | | `--block-network` | false | 許可外の通信を遮断 | | `--cpus` ／ `--memory` | 1 ／ 2Gb | サーバー1つあたりの上限 | | `--watch` | true（ホスト上） | 設定変更を自動で反映 | | `--long-lived` | false | コンテナを停止まで残す | | `--static` | false | 起動済みサーバーを使う | | `--dry-run` | false | 設定を検証して待受はしない | | `--interceptor` | なし | 呼び出しの前後に処理を挟む | `--port` の8811はソースの既定値で、`--transport` をsseかstreamingにしてポートを省くと自動で使われます。stdioのまま `--port=8811` を付けると「cannot use –port with –transport=stdio」で止まります。 ### –dry-runの検証範囲と終了動作 `--dry-run` は、イメージの取得・署名検証・ツール一覧の取得まで進めたうえで、待ち受けずに終了します。`duckduckgo` を指定した実測では「2 tools listed」「Initialized in 17.65s」のあと「Dry run mode enabled, not starting the server.」で終了コード0でした。シークレットの名前違いやイメージの取得失敗をCIで先に見つけたいときに使えます。 ### –toolsによる公開ツールの制限 `--tools` は「サーバー名:ツール名」の形で、`server1:*` とするとそのサーバーの全ツールを公開します（[リポジトリのGateway解説](https://github.com/docker/mcp-gateway/blob/v0.44.3/docs/mcp-gateway.md)の例）。ファイル削除やIssue作成など書き込み系のツールを持つサーバーは、読み取り系のツールだけを公開しておくと、AIアプリの誤操作が起きても被害を小さくできます。 ## HTTP接続（sse・streaming）の認証とバインド先 既定のstdioは起動したAIアプリとだけつながります。複数のアプリやほかのコンテナから使うにはsseかstreamingを選びます。streamingのURLは `http://localhost:8811/mcp`、sseは `/sse` です。MCPのトランスポートの違いは[Streamable HTTPとは？MCPのトランスポートとSSEの違い、2026-07-28仕様の変更点](/tech/details/6580/)で詳しく説明しています。 ### BearerトークンとMCP\_GATEWAY\_AUTH\_TOKEN [リポジトリのセキュリティモデル文書](https://github.com/docker/mcp-gateway/blob/v0.44.3/docs/security.md)によると、HTTP接続では既定でBearerトークンが必要です。環境変数 `MCP_GATEWAY_AUTH_TOKEN` があればその値を使い、無ければ起動のたびに英小文字と数字50文字のトークンを生成してログに出します。生成されたトークンは再起動で変わるため、AIアプリ側の設定を毎回書き換えることになります。常用するなら環境変数で固定してください。実測では、トークン無しの初期化要求は401、正しいトークン付きは200、`/health` はトークン無しでも200でした。`/health` はMCPの通信口ではないため、意図的に認証を外してあります。 ``` export MCP_GATEWAY_AUTH_TOKEN="$(openssl rand -hex 24)" docker mcp gateway run --transport=streaming --port=8811 --host=127.0.0.1 # 以下はGatewayを起動したまま、別ターミナルで実行する # 起動元と同じトークンを設定する（新しい値を生成しない） export MCP_GATEWAY_AUTH_TOKEN="Gatewayの起動に使ったトークン" claude mcp add --transport http docker-gateway http://127.0.0.1:8811/mcp \ --header "Authorization: Bearer ${MCP_GATEWAY_AUTH_TOKEN}" ``` ### –host未指定時の待受範囲とループバックへの制限 v0.44.3のソースでは `--host` の既定値は空文字で、その場合は全インターフェースで待ち受けます。トークンがあるのでそのまま他人に使われるわけではありませんが、社内LANやカフェのWi-Fiから接続を試みられる状態になります。手元のAIアプリだけで使うなら `--host=127.0.0.1` を付けてください。公式イメージをコンテナで動かす場合はコンテナ内で全インターフェースに待ち受ける必要があるので、代わりに上のComposeの例のように公開ポートを `127.0.0.1:8811:8811` に絞ります。 `--allow-unauthenticated` を付けると認証が外れます。そのうえで外部から届くアドレスで待ち受けると、Gatewayは「Any client that can reach this listener can execute configured MCP tools」という警告をログに出します。ファイルやGitHubを操作するツールを無認証で外へ開くことになるので、ループバック以外では使わないでください。 ### Originヘッダーによるブラウザからの要求の拒否 Gatewayは、DNSリバインディング攻撃を防ぐため、`Origin` ヘッダーの付いた要求をlocalhost・127.0.0.1・::1以外から受け付けません。実測では、正しいトークンを付けても `Origin: https://evil.example` は403でした。注意したいのは、localhostでもポートが違う `Origin: http://localhost:3000` も「Origin does not match Host」で403になった点です。この検証のようにOriginとHostのポートが異なるブラウザアプリから直接接続する構成は拒否されるため、サーバー側のプロセスを経由させてください。`Origin` を送らないCLIやSDKからの接続は影響を受けません。 ## セキュリティの既定値：署名検証・シークレット・ログ・分離 MCPサーバーはファイルや外部APIに触れるため、Gatewayを使う最大の利点はこの実行境界にあります。セキュリティモデル文書が定める既定の範囲を、実測結果と合わせて整理します。 - **署名検証**：Docker Hubの `mcp/` 名前空間のイメージに限り、取得前に署名を検証する。検証を有効にしている間はダイジェスト指定が必須。実測ログでも「Verifying images \[mcp/duckduckgo\]」「Images verified in 2.26s」が出た。名前空間外のサードパーティイメージは検証されない。 - **シークレット**：シークレットは宣言したサーバーにだけ渡り、ホストの環境変数はコンテナに引き継がれない。`--block-secrets` はツールの引数と応答を実行前後に走査する。 - **呼び出しログ**：`--log-calls` が記録するのはツール名と引数の形だけで、値は残らない。実測でも「Calling tool search with arguments: object with 2 field(s)」と記録された。誰が何を検索したかまで監査したい場合は、後述のインターセプターで別途記録する必要がある。 - **ネットワーク**：外向き通信は既定では遮断されない（実測のコンテナも `--network bridge`）。`--block-network` か、サーバー定義の `disableNetwork`・`allowHosts` で絞る。 - **ホストのディレクトリ**：カタログやプロファイルからのバインドマウントは既定で読み取り専用。書き込みを許すには `MCP_GATEWAY_DOCKER_BIND_ALLOW_WRITABLE_PATHS` に完全一致のパスを登録する。 一方、ツールの説明文に仕込まれたプロンプトインジェクションや、許可した範囲内でサーバーが悪意ある内容を返すことは、文書上もGatewayの守備範囲外と明記されています。署名検証が守るのはイメージがDockerの公開した物かどうかだけです。サーバーの振る舞いが安全かどうかまでは保証しません。MCPサーバー経由のインジェクションの実例は[Playwright MCPのセキュリティ｜危険性とCVE-2025-9611対策](/tech/details/6077/)を参照してください。 ## インターセプターによるツール呼び出しの検査・加工 インターセプターは、ツール呼び出しの前（before）か後（after）に任意の処理を挟む仕組みです。書式は `--interceptor=タイミング:種類:引数` で、種類は次の3つです（[リポジトリのインターセプター例](https://github.com/docker/mcp-gateway/blob/v0.44.3/examples/interceptors/README.md)）。 | 種類 | 書式の例 | 受け渡し | | ------ | ----------------------- | ----------------------- | | exec | `before:exec:スクリプト` | `/bin/sh -c` の標準入力にJSON | | docker | `before:docker:イメージ 引数` | コンテナの標準入力にJSON | | http | `before:http:URL` | JSONをPOST | beforeは要求全体を受け取り、標準出力（httpなら空でない応答）にJSONを返すと、ツールを呼ばずにその内容を応答にできます。afterは応答を受け取って加工できます。標準エラー出力はGatewayのログに出るので、引数の監査ログを取る用途に向きます。 ``` # 引数をGatewayのログへ出す（before） docker mcp gateway run --servers=duckduckgo \ --interceptor 'before:exec:echo Arguments=$(jq -c ".params.arguments") >&2' # 応答テキストを先頭100文字に切り詰める（after） docker mcp gateway run --servers=duckduckgo \ --interceptor 'after:exec:jq -c ".content[].text |= (.[:100])"' ``` ### streaming・sseのbeforeインターセプター不具合（Issue #358） v0.44.3でstreaming接続に `before:exec` と `after:exec` を付けて `tools/call` を送ったところ、ツールは実行されず「marshalling request: json: unsupported type: func(mcp.CloseSSEStreamArgs)」というエラーが返りました。同じ指定をstdio接続にすると、v0.44.3でもv0.43.3でもbefore・afterの両方が動き、検索結果も返りました。この現象は[Issue #358](https://github.com/docker/mcp-gateway/issues/358)として2026年1月23日に報告され、2026年10月31日時点でも未解決です。HTTP接続で監査や遮断をインターセプターに頼る設計は現時点では成り立たないので、stdioで使うか、Gatewayの手前に別のプロキシを置いてください。 ## 他社の「MCPゲートウェイ」との違いと選び方 「mcp gateway」で検索すると、IBM・Microsoft・Cloudflareなどの同名の製品が並びます。名前は同じでも、どこで動きどこまで管理するかが違います。 | 製品 | 最新版・提供状況 | 動く場所 | 得意なこと | | ----------------------------- | ------------------- | -------------- | ----------------- | | Docker MCP Gateway | v0.44.3（2026-10-26） | 手元・自前のDocker | サーバーのコンテナ隔離 | | IBM ContextForge | v1.1.0（2026-10-20） | 自前サーバー | MCP・A2A・RESTの集約管理 | | Microsoft mcp-gateway | MITのOSS | Kubernetes | リバースプロキシと管理 | | agentgateway | v1.7.0（2026-10-27） | 自前サーバー・K8s | LLM・MCP・A2Aの経路制御 | | Cloudflare MCP server portals | 2026-09-24にGA | Cloudflareのエッジ | リモートMCPの単一窓口 | [IBMのContextForge](https://github.com/IBM/mcp-context-forge)（旧称MCP Context Forge・Apache-2.0）は、MCPに加えてA2AやREST・gRPCのAPIもまとめて登録し、ツールを束ねた仮想サーバーを作れるレジストリ兼プロキシです。[Microsoftのmcp-gateway](https://github.com/microsoft/mcp-gateway)はKubernetesでの運用を前提にしたリバースプロキシで、ローカルで試す手順でもKubernetesの有効化を求めます。[agentgateway](https://agentgateway.dev/)は2025年にLinux Foundationへ寄贈されたプロジェクトで、LLM・MCP・エージェント間通信の経路制御を担います。[CloudflareのMCP server portals](https://developers.cloudflare.com/changelog/post/2026-09-24-mcp-portals-ga/)は2026年9月24日に一般提供が始まり、複数のリモートMCPサーバーを1つのHTTP窓口にまとめます。Cloudflare側の構築手順は[Cloudflare MCPとは？WorkersでリモートMCPサーバーを作る手順とMCPサーバーポータル](/tech/details/6032/)、Envoy系の選択肢は[Agent Routerとは｜Envoy AI Gateway改称後の構成とMCPゲートウェイの導入判断](/tech/details/17708/)で扱っています。 ### Docker MCP Gatewayを選ばないほうがよい場面 Docker MCP Gatewayが強いのは、開発者の手元やCIで、MCPサーバーをコンテナに閉じ込めて動かす場面です。次の条件に当てはまる場合は、別の製品を選んでください。 - **数十人規模で同じMCPサーバー群を共有し、利用者ごとの権限を管理したい**：Docker MCP Gatewayのトークンは1つで、利用者を区別しない。ContextForgeやagentgatewayのような集中管理型を選ぶ。 - **HTTP接続でツール呼び出しの監査・遮断をインターセプターに任せたい**：Issue #358が直るまでbeforeが動かない。 - **サーバーを常時インターネットに公開したい**：公開・冗長化を含めた基盤を別途設計する必要がある。CloudflareならWorkersでリモートMCPサーバー自体をホストでき、MCP server portalsで複数のサーバーを1つの窓口にまとめられる（ポータルは集約の窓口で、サーバーのホスティングはWorkers側が担う）。 社内向けのAIエージェントにMCPサーバーを組み込む構成から相談したい場合は、[AIエージェント開発の支援](https://www.issoh.co.jp/service/ai/agent/)でも対応しています。 ## よくある質問 ### Docker MCP GatewayはGitHubで公開されていますか？ はい。[docker/mcp-gateway](https://github.com/docker/mcp-gateway) としてMITライセンスで公開されています。2026年10月時点の最新はv0.44.3（2026年10月26日）で、リリースはすべてPre-release表示です。Docker Desktopに同梱される `docker mcp` プラグインの実体もこのリポジトリです。 ### docker mcp server enableが使えないのはなぜですか？ v0.44.3ではプロファイル機能が常時有効になり、`docker mcp server enable` は廃止扱いになったためです。代わりに `docker mcp profile server add` でプロファイルにサーバーを追加するか、`docker mcp gateway run --servers=サーバー名` で直接指定します。 ### Docker MCP Gatewayの既定のポート番号はいくつですか？ 既定はstdio接続なのでポートは開きません。`--transport=sse` か `--transport=streaming` を指定してポートを省くと8811で待ち受けます。`--host` を付けないと全インターフェースで待ち受ける点に注意してください。 ### Docker Desktopが無くても使えますか？ 使えます。Linuxなら `docker-mcp` バイナリをCLIプラグインとして置けば動きます。Docker Desktopの無いmacOSではプラグインが止まるため、公式イメージ `docker/mcp-gateway:v0.44.3` にDockerソケットを渡してコンテナとして起動します。 ### DuckDuckGoなどカタログのサーバーはどう指定しますか？ 従来方式なら `--servers=duckduckgo` のようにカタログのサーバー名を書きます。プロファイル方式なら `docker mcp profile server add プロファイル名 --server catalog://mcp/docker-mcp-catalog/duckduckgo` で追加し、`--profile` で起動します。DuckDuckGoサーバーはAPIキー不要で、`search` と `fetch_content` の2ツールを公開します。 ## 関連記事 - [Docker MCP Toolkitの使い方｜プロファイル作成とClaude・Cursor接続、docker mcpコマンド【2026年10月】](/tech/details/7218/) - [Streamable HTTPとは？MCPのトランスポートとSSEの違い、2026-07-28仕様の変更点](/tech/details/6580/) - [Agent Routerとは｜Envoy AI Gateway改称後の構成とMCPゲートウェイの導入判断](/tech/details/17708/) - [Cloudflare MCPとは？WorkersでリモートMCPサーバーを作る手順とMCPサーバーポータル【2026年10月】](/tech/details/6032/) - [MCP（Model Context Protocol）とは？仕組み・APIとの違い・MCPサーバーの作り方](/tech/details/5736/) --- 出典: [Docker MCP Gatewayの使い方｜docker mcp gateway runの主要オプションと認証・インターセプター【2026年10月】]()（株式会社一創）