LaunchDarklyのMCPサーバーをClaude Codeで使う手順

LaunchDarklyのMCPサーバーとは

LaunchDarklyのMCP(Model Context Protocol)サーバーは、フィーチャーフラグの操作を自然言語でAIクライアントから行うための公式サーバーです。Claude CodeやCursorなどMCP対応クライアントから接続すると、フラグの作成・更新・削除をチャットの指示だけで実行できます。

提供範囲はフィーチャーフラグ管理だけではありません。AgentControlの設定管理と、ログ・トレース・エラー・ダッシュボードを扱うobservability(可観測性)データへのアクセスも、同じMCPサーバー経由でカバーします。LaunchDarklyはこのサーバーをhosted(ホスト型)で提供しており、通常の商用アカウントはインストール作業なしでURLに接続するだけで使えます。

接続先として公式ページが挙げているクライアントは、Claude Code・Cursor・Copilot付きのVS Code・Windsurfの4つです。ただし手動設定の手順が載っているのはClaude Code・Cursor・Windsurf・GitHub Copilotで、Copilotの項は「リポジトリのSettings > Copilot > Coding agent」にJSONを貼る方式です。VS Codeの設定ファイルに書く手順ではない点に注意してください。

接続後は「defaultプロジェクトにexample featureというフラグを作成して」「example featureフラグを全環境でONにして」のような指示がそのまま通ります。ターゲティングルールの変更や、直近24時間のエラーグループの確認も同様に自然言語で依頼できます。

Claude Codeへの接続は3段階で終わる

LaunchDarklyのMCPサーバーは、Claude CodeのCLIコマンド1つで登録できます。設定ファイルを手書きする必要はありません。

claude mcp add --transport http "launchdarkly" \
    "https://mcp.launchdarkly.com/mcp/launchdarkly"

CLI以外の経路として、LaunchDarklyはインストールページも用意しています。クライアントを選ぶとプロンプトに従って接続できる仕組みで、設定を手で書きたくない場合の代替手段です。

登録先を決める:既定のlocalスコープとprojectスコープ

claude mcp add は、登録先を --scope で切り替えられます。claude mcp add --help の出力(v2.1.289)では、値は local user project の3つで、既定は local です。

-s, --scope <scope>          Configuration scope (local, user, or project)
                             (default: "local")
-t, --transport <transport>  Transport type (stdio, sse, http). Defaults to
                             stdio if not specified.

--transport を省くとstdioとして扱われます。LaunchDarklyのhostedサーバーはURL接続なので、--transport http は省けません。

--scope project を付けて同じコマンドを実行すると、.mcp.json に書き込まれ、次のように表示されます。

claude mcp add --transport http --scope project launchdarkly \
    https://mcp.launchdarkly.com/mcp/launchdarkly

Added HTTP MCP server launchdarkly with URL: https://mcp.launchdarkly.com/mcp/launchdarkly to project config
File modified: <作業ディレクトリ>/.mcp.json

.mcp.json に書かれるのは次の内容だけです。

{
  "mcpServers": {
    "launchdarkly": {
      "type": "http",
      "url": "https://mcp.launchdarkly.com/mcp/launchdarkly"
    }
  }
}

この形は、LaunchDarklyの移行手順が「追加する設定」として示しているJSONと同じです。認証はOAuthが担うため、ファイルにAPIキーもトークンも入りません。リポジトリで共有しやすい構成です。

--scope を省くと local として扱われ、~/.claude.json のそのプロジェクトの項目に書かれます。.mcp.json は作られません。自分の手元だけで試すなら既定のまま、チーム全員が同じ接続を使うなら project という使い分けです。

project スコープのサーバーは、各メンバーが初回に承認するまで ⏸ Pending approval (run `claude` to approve) の状態で止まります。claude を起動して承認すると使えるようになります。

以前のnpx版から移行する場合

過去にnpxベースのローカルサーバー(@launchdarkly/mcp-server)を --api-key 付きで設定していた場合は、hostedサーバーへの移行が必要です。既存の設定を削除して上記のURL登録に置き換えると、認証はAPIキーからOAuthへ切り替わります。

--api-key の引数や、環境変数 LD_ACCESS_TOKEN も残さず消します。手順の終わりは、AIクライアントを閉じて開き直し、サーバーを切断して再接続してOAuthをやり直す流れです。

OAuth認証に必要な権限

OAuth認証を完了させても、権限不足だと操作は失敗します。MCPサーバーはフラグとAgentControl設定の作成・読み取り・更新・削除にアクセスするため、認証に使うLaunchDarklyアカウントには十分な権限が必要です。

LaunchDarklyが推奨するのは、Writerのbase role(基本ロール)、LaunchDarkly Developerのpreset role(プリセットロール)、またはこれらと同等のアクセス権を持つロールです。カスタムロールを使っている場合は、接続先のプロジェクトと環境へのアクセスがロールに含まれているかを見ます。

OAuth同意画面を通過した直後に403エラーが出る場合、公式ページはOAuth自体の失敗ではなく、使ったアカウントの権限不足がよくある原因だと説明しています。症状に合わせて、次の順で切り分けます。

3つを試しても403が続くなら、LaunchDarklyサポートへの問い合わせが次の窓口です。

使えるツールとエージェントスキル

hostedサーバーが公開するMCPツールは、フィーチャーフラグ管理・AgentControl・observability・メトリクスの4領域に絞り込まれています。個々のツール名を含む完全な一覧は、MCPサーバーのページの「Available Tools」セクションに載っています。Claude Codeでは /mcp でサーバーごとのツール数を見られます。

単発のツール呼び出しでは対応しきれない複雑な手順には、LaunchDarklyが公開するagent skillsを組み合わせます。agentskills.ioが定めるオープン標準に沿ったスキル集で、Claude Code・Cursor・VS Code・Windsurf・Codexなど、標準に対応するエディタで共通に動きます。

npx skills add launchdarkly/agent-skills

スキルとMCPツールの役割は異なります。MCPツールはLaunchDarklyのリソースを直接操作する手段そのものです。スキルは、複数のツール呼び出しを正しい順番で実行させるための手順書にあたります。「old-checkoutフラグを片付けて」と指示したときの launchdarkly-flag-cleanup スキルは、エージェントを次の順で導きます。

スキルが無いと、エージェントは正しいツールを呼べても、順序を誤ったりコード参照の確認を飛ばしたりします。判定を毎回同じ手順で踏ませるのが、スキルの役割です。エージェント自体の実行環境をどう組むかは、Agent Skillsとは何かが全体像を扱っています。

hostedサーバーとlocalサーバーの使い分け

LaunchDarklyのMCPサーバーには2種類あり、どちらを使えるかは、アカウントが所属する環境で決まります。federal(連邦)環境とEU環境のアカウントはhostedサーバーを使えないため、自己管理型のlocalサーバーが唯一の選択肢です。

LaunchDarklyは、hostedサーバーが使えるcommercial環境のアカウントには常にそちらを使うよう案内しています。理由は、hostedのほうが機能がそろっていて、更新も頻繁なことです。

localサーバーのバイナリはGitHub Releasesから対象プラットフォーム向けの実行ファイルを取得する方式です。DockerはAWS Marketplaceで配布されるイメージをコンテナとして起動します。

操作の範囲はもう少し細かく分かれています。localサーバーのGitHub READMEが挙げる操作は、次のとおりです。

• フィーチャーフラグ: 一覧・取得・作成・更新・削除と、環境をまたいだ状態の取得
• AI Config(LLM向けプロンプト設定): 一覧・取得・作成・更新・削除、ターゲティングの取得と更新、バリエーションの作成・取得・更新・削除
• 監査ログ: エントリの一覧取得
• コード参照: リポジトリの一覧取得
• 環境: プロジェクトに紐づく環境の一覧取得

よくあるつまずき

federal・EUアカウントでhostedのURLに接続しようとすると、そもそも接続先が用意されていません。この場合はlocalサーバーの --server-url 引数に、環境ごとのURLを指定して起動します。

localサーバーをnpxで起動する構成では、--api-key にAPIキーを直書きする設定例がドキュメントに載っています。共有リポジトリにコミットする設定ファイルへの直書きは避け、環境変数経由に切り替える方法があります。READMEには $LD_ACCESS_TOKEN を env で渡す設定例もあります。

ただし、設定ファイル内で環境変数を展開できないクライアントもあります。READMEはCursorを例に挙げ、回避策としてローカルのスクリプトを設定から呼び出す方法の参照先(GitHub issueのコメント)を載せています。対応状況は、使うクライアントのドキュメントで確かめます。

READMEのDocker向け設定例には、もう1つ注意点があります。env ブロックの後ろにカンマが無く、そのまま貼るとJSONとして読み込めません。貼る前に構文を直します。

localサーバーでは、args に "--scope", "read" を足すと権限を読み取りに絞れます。"--tool", "<tool>" を足すと、有効にするツールを選べます。

hostedサーバーへの移行時に古いローカル設定を消し忘れると、旧サーバー(LaunchDarkly)と新サーバー(launchdarkly)が並んで登録されます。先に旧設定を削除してから、URL登録を追加します。

まとめ

チームで接続を揃えるなら --scope project を付けて .mcp.json に残し、手元で試すだけなら既定のlocalスコープで足ります。

環境で選ぶ道は決まっています。commercialならhosted、federalとEUならlocalです。フラグ削除のように順序が大事な作業は、agent skillsを組み合わせると毎回同じ手順で進みます。MCPサーバーをゼロから自作する場合はMCPサーバー自作ガイド、CursorでのMCP設定はCursor MCP設定ガイド、同様のSaaS連携はFigma MCPサーバーの使い方が参考になります。