unleash-mcp

Unleash MCP サーバー

Unleash のフィーチャーフラグを管理する、目的に特化した Model Context Protocol（MCP）サーバーです。このサーバーにより、LLM を活用したコーディングアシスタントは Unleash のベストプラクティスに従ってフィーチャーフラグを作成、管理できます。

ご意見をお寄せいただくには、コミュニティ Slack に参加するか、GitHub で issue を作成してください。

概要

この MCP サーバーは Unleash Admin API と連携するツールを提供し、AI コーディングアシスタントが次のことを行えるようにします。

• フィーチャーフラグを作成します。適切な検証と型付けが適用されます。
• 既存のフラグを検出し、重複を防止するか、再利用を促します。
• 変更を評価し、フィーチャーフラグが必要かどうかを判断します。
• 進行状況をストリーミングし、操作中の状況を確認できるようにします。
• エラーを適切に処理し、役立つヒントを提示します。
• ユーザーが同意した場合に限り、send_feedback を通じて MCP に関する問題を Unleash に報告します。
• Unleash のドキュメントのベストプラクティスに従います。

利用可能なツール

MCP サーバーは次のツールを公開します。

• create_flag：Unleash にフィーチャーフラグを作成します。
• evaluate_change：リスクを評価し、フィーチャーフラグの使用を推奨します。
• detect_flag：既存のフィーチャーフラグを見つけ、重複を防ぎます。
• wrap_change：変更をフィーチャーフラグでラップする方法を提示します。
• set_flag_rollout：各環境でフィーチャーフラグの対象となるユーザーを設定します。ロールアウトの割合、セグメント、制約、および環境を有効にするかどうかを指定できます。
• create_targeting：プロジェクト内、またはすべてのプロジェクトに対して、set_flag_rollout の対象となるコンテキストフィールドとセグメントを作成します。
• get_flag_state：フィーチャーフラグのメタデータと有効化戦略を提示します。
• get_flag_history：イベントログからフィーチャーフラグの最近の変更を返します。各変更について、変更内容、変更者、変更時刻、環境を差分として示します。
• evaluate_flag：環境内で、Unleash コンテキスト（ユーザー ID やカスタムプロパティなど）に基づいて単一のフィーチャーフラグを評価し、どの戦略が一致したかを説明します。
• list_flags：プロジェクト内のすべてのフィーチャーフラグを一覧表示します。ページネーションと並べ替え順序を任意で指定できます。
• search_flags：すべてのプロジェクトで、名前または説明の一部を使って有効なフィーチャーフラグを検索するか、フルネームからフラグとそのプロジェクトを検索します。
• list_projects：設定済みのトークンで利用可能な Unleash プロジェクトを一覧表示します。ページネーションを任意で指定できます。
• toggle_flag_environment：環境内でフィーチャーフラグを有効または無効にします。
• remove_flag_strategy：環境からフィーチャーフラグの戦略を削除します。
• update_flag_lifecycle：フィーチャーフラグを完了、未完了、アーカイブ、復活させるか、古いものとしてマークします。
• update_project_settings：プロジェクトのデフォルトのスティッキネス（Enterprise のみ）と各環境のデフォルト戦略を設定し、既存の環境をプロジェクトに追加します。
• cleanup_flag：フラグで制御されたコードパスを安全に削除するための手順を生成します。
• send_feedback：ツール呼び出しの失敗、未対応のリクエスト、または予期しない結果を Unleash に報告し、MCP の改善に役立てます。ユーザーの同意が必要です。UNLEASH_MCP_SEND_FEEDBACK=false またはサーバーオプションの feedbackConsent によって同意が事前に拒否されている場合、このツールは一覧に表示されません。

コアワークフロー

AI アシスタントのコアワークフローは、次のように設計されています。

1. evaluate_change：まず、コード変更を評価してフラグが必要かどうかを確認します。
2. detect_flag：重複するフラグの作成を防ぐため、このツールは通常 evaluate_change によって自動的に呼び出されます。
3. create_flag：新しいフラグが必要な場合、このツールで Unleash に作成します。
4. wrap_change：最後に、このツールが新しいフラグを実装するための言語別コードを提示します。

コアワークフローツールの詳細については、ツールリファレンスセクションを参照してください。

前提条件

サーバーを実行するには、以下が必要です。

• Node.js 22 以降
• pnpm パッケージマネージャーまたは npm
• Unleash インスタンス（ホスト型またはセルフホスト型）
• フィーチャーフラグを作成する権限を持つ個人用アクセストークン

はじめに

このセクションでは、Unleash MCP サーバーをインストールして実行するさまざまな方法を説明します。エージェント（Claude Code や Codex など）向けのセットアップに従う方法、npx を使って MCP をスタンドアロンプロセスとして実行する方法、またはローカル開発環境をセットアップする方法があります。

エージェントのセットアップ

MCP サーバーは Claude Code または Codex に直接追加できます。エージェントの設定はパスごとに異なります。MCP を使用するプロジェクトのルートディレクトリから、以下のコマンドを実行してください。

Claude Code の場合：

claude mcp add unleash \
    --env UNLEASH_BASE_URL={{your-instance-url}} \
    --env UNLEASH_PAT={{your-personal-access-token}} \
    -- npx -y @unleash/mcp@latest --log-level error

Codex の場合：

codex mcp add unleash \
    --env UNLEASH_BASE_URL={{your-instance-url}} \
    --env UNLEASH_PAT={{your-personal-access-token}} \
    -- npx -y @unleash/mcp@latest --log-level error

リモートエージェントのセットアップ（実験的）

MCP サーバーをローカルで実行する代わりに、HTTP 経由で Unleash インスタンスに組み込まれたリモート MCP サーバーに直接接続できます。これはストリーミング可能な HTTP トランスポートを使用するため、ローカルプロセスは不要です。

注： リモート MCP は、Unleash インスタンスで有効化する必要がある実験的な機能です。有効化するには Unleash チームにお問い合わせください。

OAuth

OAuth フローではブラウザーが開き、Unleash にログインすると、有効期間の短い PAT が自動的に発行されます。トークンを手動で管理する必要はありません。

Claude Code の場合：

claude mcp add unleash https://{{your-instance-url}}/api/admin/mcp --transport http

Codex の場合：

codex mcp add unleash https://{{your-instance-url}}/api/admin/mcp --transport http

初回使用時に、クライアントが自動的にブラウザーを開いてログインします。Unleash で認証すると PAT が作成され、その後のすべてのリクエストで使用されます。

PAT の有効期限は、デフォルトで 24 時間です。

個人用アクセストークン（PAT）

すでに PAT をお持ちの場合、またはヘッドレス／非対話型のアクセス（CI パイプライン、共有開発環境、OAuth に対応していないクライアント）が必要な場合は、この方法を使用してください。

PAT を作成するには、Unleash インスタンスにログインし、Profile > Personal Access Tokens に移動して、新しいトークンを作成します。

Claude Code の場合：

claude mcp add unleash https://{{your-instance-url}}/api/admin/mcp \
  --transport http \
  --header "Authorization: Bearer {{your-personal-access-token}}"

Codex の場合：

codex mcp add unleash https://{{your-instance-url}}/api/admin/mcp \
  --transport http \
  --header "Authorization: Bearer {{your-personal-access-token}}"

--header フラグを使うと、OAuth フローを完全に回避して PAT を直接送信できます。

npx を使ったクイックスタート

リポジトリをクローンせずに、npx を使って MCP サーバーをスタンドアロンプロセスとして実行できます。コマンドを実行するディレクトリで、環境変数またはローカルの .env ファイルを使って設定を指定してください。

UNLEASH_BASE_URL={{your-instance-url}} \
UNLEASH_PAT={{your-personal-access-token}} \
UNLEASH_DEFAULT_PROJECT={{default_project_id}} \
npx @unleash/mcp@latest --log-level debug

CLI では、ローカルビルドと同じフラグ（例：--dry-run、--log-level）を使用できます。

ローカル開発環境のセットアップ

ローカル開発用にプロジェクトをセットアップするには、以下の手順に従ってください。

1. 依存関係をインストールする

リポジトリをクローンし、pnpm を使って依存関係をインストールします。Corepack を使うと、全員が同じ pnpm バージョンを使用できます。

git clone https://github.com/Unleash/unleash-mcp.git
cd unleash-mcp

# Enable Corepack once per machine, then prepare the pnpm this repo expects
corepack enable
corepack prepare [email protected] --activate

pnpm install

2. Claude または Codex から開発モードで直接実行する

npm run の出力や tsx watch のバナーは、余分な標準出力によって MCP のハンドシェイクが失敗するため、表示されないようにしてください。出力を抑える方法は次の 2 つです。

A) コンパイル済み JS を使う（最も確実）

npm run build
# or keep it hot in another terminal: npm run build:watch

claude mcp add unleash-dev \
  --env UNLEASH_BASE_URL={{your-instance-url}} \
  --env UNLEASH_PAT={{your-personal-access-token}} \
  --env LOG_LEVEL=debug \
  --env APP_LOG_FILE="$(pwd)/app.log" \
  --env MCP_STDIO_LOG_FILE="$(pwd)/mcp-stdio.log" \
  -- node "$(pwd)/dist/index.js"

codex mcp add unleash-dev \
  --env UNLEASH_BASE_URL={{your-instance-url}} \
  --env UNLEASH_PAT={{your-personal-access-token}} \
  --env LOG_LEVEL=debug \
  --env APP_LOG_FILE="$(pwd)/app.log" \
  --env MCP_STDIO_LOG_FILE="$(pwd)/mcp-stdio.log" \
  -- node "$(pwd)/dist/index.js"

B) TypeScript を直接使う（ビルド不要）

claude mcp add unleash-dev \
  --env UNLEASH_BASE_URL={{your-instance-url}} \
  --env UNLEASH_PAT={{your-personal-access-token}} \
  --env LOG_LEVEL=debug \
  --env APP_LOG_FILE="$(pwd)/app.log" \
  --env MCP_STDIO_LOG_FILE="$(pwd)/mcp-stdio.log" \
  -- node --no-warnings --import tsx "$(pwd)/src/index.ts"

codex mcp add unleash-dev \
  --env UNLEASH_BASE_URL={{your-instance-url}} \
  --env UNLEASH_PAT={{your-personal-access-token}} \
  --env LOG_LEVEL=debug \
  --env APP_LOG_FILE="$(pwd)/app.log" \
  --env MCP_STDIO_LOG_FILE="$(pwd)/mcp-stdio.log" \
  -- node --no-warnings --import tsx "$(pwd)/src/index.ts"

注：

• node --import tsx は出力が静かで（npm のライフサイクル出力なし）、TS を直接実行します。ビルドを避けたい場合に使用してください。
• node dist/index.js が最も安全な選択肢です。エージェントのコマンドを安定させたまま変更時に再ビルドできるよう、npm run build:watch と組み合わせてください。
• ログはリポジトリのルートディレクトリ（app.log、mcp-stdio.log）に保存されます。どちらも gitignore に登録されています。

ログ制御

• LOG_LEVEL（推奨）：アプリケーションのログ出力レベル（debug、info、warn、error）を制御します。未設定の場合、デフォルトはerrorです。
• --log-level CLI フラグ：一時的に変更したい場合に、LOG_LEVELを任意で上書きします。
• APP_LOG_FILE（任意）：設定すると、アプリケーションログはこのファイルに書き込まれます（標準出力には書き込まれません）。未設定の場合、ログは標準エラー出力に送られます。
• MCP_STDIO_LOG_FILE（任意）：設定すると、MCP の標準入力／標準出力／標準エラー出力が、チャネルのプレフィックス付きでこの単一のファイルにティー出力されます。プロトコルメッセージは通常どおり標準出力を通じて送信されます。

クライアントの識別情報

MCP クライアントが初期化時にclientInfoを送信すると（Claude Code、Cursor、Copilot、Windsurf、Codex、Kiro、およびその他の仕様に準拠したクライアント）、サーバーは送信する Unleash Admin API 呼び出しのUser-Agentヘッダーに情報を追加します。

User-Agent: unleash-mcp/<version> (MCP Server; client=claude-code/1.2.3)

これにより、サーバー側を変更することなく、Unleash のイベントログで「どの AI ツールがこのフラグを作成または切り替えたか」を確認できます。識別情報の値は、User-Agentヘッダーを壊さないようにサニタイズされます。

UNLEASH_MCP_CLIENT_ATTRIBUTION=offを設定すると、情報の追加を無効にし、unleash-mcp/<version> (MCP Server)に戻せます。デフォルトでは有効です。

ツールのリファレンス

このセクションでは、中核となる各ツールの目的、パラメーター、出力などについて詳しく説明します。

変更を加える前に、これらのツールはプロジェクトの変更リクエスト設定とユーザーの権限を確認します。Unleash の UI と同様に、変更に承認が必要な場合、set_flag_rollout、toggle_flag_environment、remove_flag_strategyは管理者を含めて変更リクエストに変更を登録します。ただし、そこでSKIP_CHANGE_REQUESTが設定されている場合は、直接書き込みます。update_flag_lifecycleによるアーカイブは、いずれかの環境で変更リクエストが有効な間は、すべてのユーザーについて変更リクエストに登録され、最初に本番環境で適用されます。結果はrequestedと変更リクエストのid、url、stateを含むoutcome: "pendingApproval"となり、それ以外の場合はoutcome: "saved"となります。

変更は、その環境で現在開いている変更リクエスト、または新しい変更リクエストに登録され、そのフラグについてすでに保留中の変更に反映されます。そのため、後続の変更は2つ目の変更として追加されるのではなく、保留中の変更を更新します。すでに保留中の変更を繰り返しても何も追加されません。また、現在有効な設定を指定すると、それを取り消す変更が追加されるのではなく、保留中の変更が削除されます。新しい変更リクエストがレビューに送られるのは、これらの変更だけが含まれている場合です。すでに作成していたドラフトは送信されないため、準備ができたら Unleash で送信できます。レビュー中または承認済みの変更リクエストに変更を追加すると、承認はリセットされます。すでにアーカイブが保留中のフラグをアーカイブしても、何も追加されません。

フラグの作成

create_flagツールは、包括的な検証と進行状況の追跡を行いながら、Unleash に新しいフィーチャーフラグを作成します。

使用するタイミング

フィーチャーフラグが必要だとすでに判断しており（たとえば、evaluate_changeを実行した後）、適切なタイプとメタデータを指定して作成する段階で、このツールを使用します。

パラメーター

このツールは、次のパラメーターを受け取ります。

• name（必須）：プロジェクト内で一意のフィーチャーフラグ名。
• type（必須）：ライフサイクルと用途を示すフィーチャーフラグのタイプ。
  • release：ユーザーへの段階的なフィーチャーリリース。
  • experiment：A/B テストと実験。
  • operational：システムの動作と運用上の切り替え。
  • kill-switch：緊急停止やサーキットブレーカー。
  • permission：ユーザーのロールや権限に基づくフィーチャーへのアクセス制御。
• description（必須）：フラグが制御する内容と、そのフラグが存在する理由を明確に説明します。
• projectId（任意）：対象プロジェクト（デフォルトはUNLEASH_DEFAULT_PROJECT）。
• impressionData（任意）：分析トラッキングを有効にします（デフォルトはfalse）。

使用例

エージェントのプロンプト

Use create_flag with:
- name: "new-checkout-flow"
- type: "release"
- description: "Gradual rollout of the redesigned checkout experience"
- projectId: "ecommerce"

ツールのペイロード

{
  "name": "new-checkout-flow",
  "type": "release",
  "description": "Gradual rollout of the redesigned checkout experience with improved conversion tracking",
  "projectId": "ecommerce",
  "impressionData": true
}

ツールの出力

成功すると、このツールは、新しいフィーチャーフラグの Unleash Admin UI における URL、MCP リソース URI、作成日時、および設定の詳細を含む JSON オブジェクトを返します。

変更の評価

evaluate_change ツールは、コード変更をフィーチャーフラグの背後に置くべきかどうかを評価します。変更の構造、コンテキスト、潜在的なリスクを調べ、説明と次のステップを添えた推奨事項を返します。

使用するタイミング

フィーチャーや変更に着手する際、その作業にフィーチャーフラグが必要かどうかを把握したい場合は、evaluate_change を使用します。どの種類のフラグを使うべきか分からない場合や、ロールアウトの計画についてガイダンスが必要な場合にも役立ちます。

動作の仕組み

このツールは、Unleash のベストプラクティスに基づき、LLM アシスタント向けの詳細な Markdown 形式のガイダンスを返します。

ガイダンスには、以下が含まれます。

• 親フラグの検出：コードが既存のフラグで保護されているかどうかを確認します。
• リスク評価：コードパターンを分析し、リスクのある操作を特定します。
• コード種別の評価：変更を分類します（例：テスト、設定、フィーチャー、バグ修正）。
• 推奨事項：フラグを作成するか、既存のフラグを使うか、フラグを使わないかを提案します。
• 次のアクション：次に行うことを具体的に示します。

evaluate_change がフラグが必要だと判断した場合、以下を行うよう明示的に指示します。

1. create_flag ツールを呼び出して、フィーチャーフラグを作成します。
2. wrap_change ツールを呼び出して、言語固有のコードラップのガイダンスを取得します。
3. 検出されたパターンに従って、ラップしたコードを実装します。

評価プロセス

このツールは、明確な評価プロセスに従います。

Step 1: Gather code changes (git diff, read files)
        ↓
Step 2: Check for parent flags (avoiding nesting)
        ↓
Step 3: Assess code type (test? config? feature?)
        ↓
Step 4: Evaluate risk (auth? payments? API changes?)
        ↓
Step 5: Calculate risk score
        ↓
Step 6: Make recommendation
        ↓
Step 7: Take action (create flag or proceed without)

リスク評価

このツールは、言語に依存しないパターンを使用してリスクをスコアリングします。

• 重大なリスク（スコア +5）：例として、認証、支払い、セキュリティ、データベース操作があります。
• 高リスク（スコア +3）：例として、API の変更、外部サービス、新しいクラスがあります。
• 中リスク（スコア +2）：例として、非同期操作や状態管理があります。
• 低リスク（スコア +1）：例として、バグ修正、リファクタリング、小規模な変更があります。

該当するカテゴリのスコアは累積されます。合計スコアは、次のリスクレベルに対応します。

• 重大：スコア ≥ 5
• 高：スコア ≥ 3
• 中：スコア ≥ 2
• 低：スコア < 2

出力には、LLM が自己評価した確信度を表す confidence スコア（0-1）が含まれます。提供されるコンテキストが多いほど、このスコアは高くなります。

除外カテゴリには、内容にかかわらずフィーチャーフラグが不要なファイルが含まれます。テストファイル（*.test.ts、*_test.go など）、設定ファイル（*.config.js、.env、*.yaml）、ドキュメントファイル（*.md、docs/**）が該当します。除外対象のファイルだけに限定された変更では、フラグの推奨は行われません。

カテゴリごとのキーワード、ファイル glob、コードパターン、判定理由を含むパターン定義の全容は、src/evaluation/riskPatterns.ts にあります。

親フラグの検出

このツールは、次のような言語を問わない一般的なパターンを探します。

• 条件分岐：if (isEnabled('flag'))、if client.is_enabled('flag'):
• 代入：const enabled = useFlag('flag')
• フック：const enabled = useFlag('flag') → {enabled && <Component />}
• ガード：if (!isEnabled('flag')) return;
• ラッパー：withFeatureFlag('flag', () => {...})

パラメーター

すべてのパラメーターは省略可能ですが、コンテキストを多く提供するほど推奨事項の精度が高まります。

• repository（文字列）：リポジトリ名またはパス。
• branch（文字列）：現在のブランチ名。
• files（配列）：変更対象のファイル一覧。
• description（文字列）：変更の説明。
• riskLevel（列挙型）：ユーザーが評価した low、medium、high、critical のいずれか。
• codeContext（文字列）：親フラグの検出に使用する周辺コード。

使用例

エージェントへのプロンプト

エージェントにコンテキストを収集させるシンプルな使い方です：

Use evaluate_change to help me determine if I need a feature flag

明示的な指示：

Use evaluate_change with:
- description: "Add Stripe payment processing"
- riskLevel: "high"

ツールのペイロード

{
  "repository": "my-app",
  "branch": "feature/stripe-integration",
  "files": ["src/payments/stripe.ts"],
  "description": "Add Stripe payment processing",
  "riskLevel": "high",
  "codeContext": "surrounding code for parent flag detection"
}

ツールの出力

評価結果を含む JSON オブジェクトを返します。これには、needsFlag のブール値、recommendation（例：「create_new」）、推奨されるフラグ名、リスクレベル、詳細な explanation が含まれます。

{
  "needsFlag": true,
  "reason": "new_feature",
  "recommendation": "create_new",
  "suggestedFlag": "stripe-payment-integration",
  "riskLevel": "critical",
  "riskScore": 5,
  "explanation": "This change integrates Stripe payments, which is critical risk...",
  "confidence": 0.9
}

フラグの検出

detect_flag ツールは、コードベース内の既存のフィーチャーフラグを見つけ、重複して作成するのではなく再利用できるようにします。このツールは evaluate_change ワークフローに自動的に統合されていますが、手動でも使用できます。

使用するタイミング

新しいフィーチャーフラグを作成する前、またはコードを評価する際にこのツールを使用して、ユースケースをすでにカバーしている可能性のある既存のフラグを確認します。これにより、フラグの重複を防げます。

仕組み

このツールは包括的な検索手順を返し、複数の検出方法を使用します。

• ファイルベースの検出：変更対象のファイルを検索し、既存のフラグを探します。
• Git 履歴の分析：コミット履歴から最近追加されたフラグを探します。
• 意味に基づく名前の照合：説明を既存のフラグ名と照合します。
• コードコンテキストの分析：変更箇所の周辺コードを調べます。

次に、ツールはスコアリング処理を行います。

Step 1: Execute file-based search (grep for flag patterns in target files)
        ↓
Step 2: Search git history for recent flag additions
        ↓
Step 3: Perform semantic matching (description → flag names)
        ↓
Step 4: Analyze code context (if provided)
        ↓
Step 5: Combine scores from all methods
        ↓
Step 6: Return best candidate with confidence score

信頼度レベル

ツールは信頼度スコア付きの候補を返します。

• 高 ≥0.7：強い一致です。再利用が推奨されます。
• 中 0.4-0.7：一致の可能性があります。手動で確認してください。
• 低 <0.4：一致の可能性は低く、新しいフラグを作成するのが妥当です。

パラメーター

• description（必須）：変更または機能の説明です。例："payment processing with Stripe"、"new checkout flow"。
• files（任意）：変更対象のファイルです。例：["src/payments/stripe.ts", "src/checkout/flow.ts"]。
• codeContext（任意）：フラグを検索する周辺コードです。

使用例

エージェントへのプロンプト

フラグを作成する前に、既存のフラグを確認します：

Use detect_flag with description "payment processing with Stripe"

評価時に自動的に統合：

Use evaluate_change - automatically searches for existing flags

ツールのペイロード

{
  "description": "payment processing with Stripe",
  "files": ["src/payments/stripe.ts"]
}

ツールの出力

フラグが見つかったかどうかを示す JSON オブジェクトを返します。flagFound が true の場合、フラグ名、場所、信頼度スコア、一致した理由を含む candidate オブジェクトが含まれます。

一致が見つかった場合：

{
  "flagFound": true,
  "candidate": {
    "name": "stripe-payment-integration",
    "location": "src/payments/stripe.ts:42",
    "context": "if (client.isEnabled('stripe-payment-integration')) {",
    "confidence": 0.85,
    "reasoning": "Found in same file you're modifying, added 2 days ago",
    "detectionMethod": "file-based"
  }
}

一致が見つからなかった場合：

{
  "flagFound": false,
  "candidate": null
}

変更のラップ

wrap_change ツールは、コードをフィーチャーフラグでラップするための、言語ごとのコードスニペットとガイダンスを生成します。LLM と開発者がコードベース内の既存のパターンに従い、フラグを正しく使用できるよう支援します。

使用するタイミング

create_flag を使ってフィーチャーフラグを作成した後、コードに実装する必要がある場合にこのツールを使用します。既存のコードベースのパターンに従っていることを確認したい場合や、フレームワーク固有の例（例：React、Django）が必要な場合に特に便利です。

仕組み

このツールは、evaluate_change → create_flag → wrap_change ワークフローの最終ステップです。

ツールの応答では、次のガイダンスが提供されます。

1. 検索手順：grep を使ってコードベース内の既存のフラグパターンを見つけるための、段階的なガイドです。
2. パターンの検出：一般的なパターン（例：インポート、クライアント変数名、メソッド名、ラップ方法）を特定します。
3. デフォルトのテンプレート：パターンが見つからない場合に使う代替コードスニペットです。
4. フレームワーク固有の例：React、Express、Django などに特化したパターンです。
5. 複数のパターン：if ブロック、ガード節、フック、デコレーター、ミドルウェアなどです。

サポートされている言語とフレームワーク：

• TypeScript/JavaScript：Node.js、React Hooks、Express middleware。
• Python：FastAPI、Django、Flask decorators。
• Go：標準的な if ブロック、HTTP middleware。
• Ruby：Rails controllers。
• PHP：Laravel controllers。
• C#：.NET/ASP.NET controllers。
• Java：Spring Boot。
• Rust：Actix/Rocket handlers。

パラメーター

• flagName（必須）：コードをラップする機能フラグ名です。例：「"new-checkout-flow"」や「"stripe-integration"」です。
• language（任意）：プログラミング言語です。指定しない場合は、fileName から自動検出されます。対応言語：typescript、javascript、python、go、ruby、php、csharp、java、rust
• fileName（任意）：変更するファイル名です（言語の検出に役立ちます）。例：「"checkout.ts"」、「"payment.py"」、「"handler.go"」です。
• codeContext（任意）：既存のパターンを検出するための周辺コードです。
• frameworkHint（任意）：専用テンプレートに使用するフレームワークです。例：「"React"」、「"Express"」、「"Django"」、「"Rails"」、「"Spring Boot"」です。

使用例

エージェントのプロンプト

Use wrap_change with:
- flagName: "new-checkout-flow"
- fileName: "src/components/checkout.ts"
- frameworkHint: "React"

ツールのペイロード

{
  "flagName": "new-checkout-flow",
  "fileName": "checkout.ts",
  "frameworkHint": "React"
}

ツールの出力

コードをラップする方法をユーザーに案内する、包括的な Markdown 形式の文字列を返します。クイックスタート、検索手順、プレースホルダーを使ったラップ手順、その言語で利用できるすべてのテンプレート、SDK ドキュメントへのリンクが含まれます。

# Feature Flag Wrapping Guide: "new-checkout-flow"

**Language:** TypeScript
**Framework:** React

## Quick Start
[Recommended pattern with import and usage]

## How to Search for Existing Flag Patterns
[Step-by-step Grep instructions]

## How to Wrap Code with Feature Flag
[Wrapping instructions with examples]

## All Available Templates
[If-block, guard clause, hooks, ternary, etc.]

フラグのロールアウトを設定する

set_flag_rollout ツールは、1 つ以上の環境で機能フラグの対象ユーザーを設定します。設定できるのは、ロールアウト率、セグメントによる絞り込み、コンテキストフィールドに対する制約による絞り込み、各環境を有効にするかどうかです。

変更を加える前に、リクエスト全体を検証します。すべての環境、セグメント名、コンテキストフィールド、制約値が対象です。セグメント名または変更するストラテジーが不明確な場合、MCP クライアントがフォームを表示できれば、選択肢から選ぶようユーザーに尋ねます。それができない場合、エージェントがユーザーに提示できる有効な選択肢をエラーに列挙します。

各環境では：

• ストラテジーがない場合、エントリーにストラテジーフィールドが設定されていれば、flexibleRollout ストラテジーを追加します。ロールアウトは対象ユーザーの 100％がデフォルトで、スティッキネスは default がデフォルトです。enabled: true のみを指定したエントリーでは何も追加されないため、Unleash はプロジェクトのデフォルトストラテジーを環境に適用します。
• flexibleRollout ストラテジーが 1 つの場合、そのストラテジーを更新します。省略したフィールドの値は保持されるため、{ rolloutPercentage: 100 } とすると、セグメント、制約、スティッキネス、バリアントを維持したままロールアウト率が 100％になります。
• ストラテジーが複数ある場合は、strategyId が必要です。
• 環境を有効にする前にストラテジーを保存するため、Unleash がプロジェクトのデフォルトストラテジーをその横に追加することはありません。環境を無効にする場合は保存前に無効にするため、新しいストラテジーがその環境で有効になることはありません。
• ストラテジーがすべて無効になっている環境を有効にすると、すべてのストラテジーが再び有効になります。

使用するタイミング

create_flag の後にこのツールを使ってフラグをロールアウトし、その後も対象ユーザーを変更するときに使います。たとえば、ロールアウト率を 30％から 100％に引き上げる場合です。

パラメーター

• featureName（必須）：機能フラグ名。
• projectId（任意）：プロジェクト ID（デフォルトは UNLEASH_DEFAULT_PROJECT）。
• environments（必須）：環境ごとに 1 つのエントリーを指定します。各エントリーには以下を含めます。
  • environment（必須）：環境名。例："production"。
  • rolloutPercentage（任意）：対象ユーザーのうち、フラグを受け取るユーザーの割合（0～100）。
  • segments（任意）：ユーザーが指定したセグメント名。大文字と小文字、スペース、ハイフンは区別されません。[] を指定すると、すべてのセグメントが削除されます。
  • constraints（任意）：制約。各制約には contextName、operator（Unleash の制約演算子のいずれか）、values または value、inverted、caseInsensitive を指定します。[] を指定すると、すべての制約が削除されます。
  • strategyId（任意）：環境に複数のストラテジーがある場合に変更するストラテジー。
  • strategyMode（任意）："update"（デフォルト）は既存のストラテジーを変更します。"add" は既存のストラテジーに加えて新しい flexibleRollout ストラテジーを追加します。
  • stickiness（任意）：スティッキネスのフィールド。新しいストラテジーでは "default" が使用されます。
  • groupId（任意）：スティッキネスのバケット分けに使用するグループ ID。新しいストラテジーではフラグ名が使用されます。
  • title（任意）：ストラテジーの説明的なタイトル。
  • strategyDisabled（任意）：ストラテジーを削除せずに一時停止します。これは、環境でフラグをオフにする enabled: false とは異なります。
  • variants（任意）：ストラテジーのバリアント。各バリアントには name、weight（0～1000）、weightType、stickiness、payload を指定します。[] を指定すると、すべてのバリアントが削除されます。
  • enabled（任意）：環境をオンまたはオフにします。true を指定すると、strategyDisabled が渡されない限り、無効になっていたストラテジーもオンになります。

使用例

エージェントのプロンプト

Turn on new-checkout-flow in development, and roll it out to 30% of beta users in production.

ツールのペイロード

{
  "featureName": "new-checkout-flow",
  "projectId": "ecommerce",
  "environments": [
    { "environment": "development", "enabled": true },
    {
      "environment": "production",
      "rolloutPercentage": 30,
      "segments": ["beta users"],
      "enabled": true
    }
  ]
}

ツールの出力

各環境について、ストラテジーを追加、更新、または変更しなかったかどうか、環境がオンかどうか、保存されたロールアウト率、セグメント名、制約を返します。更新の場合は、変更前の値も表示されます。環境がオフになっている場合や、適用される他のストラテジーが残っている場合など、ロールアウトを制限する要因は注記に表示されます。また、Unleash Admin UI、Admin API、フラグの MCP リソース URI にあるフラグへのリンクも結果に含まれます。

エラー

リクエストに問題がある場合、変更は行われません。エラーコードは INVALID_ROLLOUT で、problems にはすべての問題が一度に列挙されます。それぞれに環境、コード、メッセージ、ヒントが含まれ、有効な options がある場合はその一覧も含まれます。

コード	発生条件
ENVIRONMENT_NOT_FOUND	フラグにその名前の環境がありません。options にはその環境の一覧が含まれます。
DUPLICATE_ENVIRONMENT	同じ環境が複数のエントリに含まれています。
SEGMENT_NOT_FOUND	プロジェクトが使用できるセグメントのうち、名前が一致するものがない、一致するものが複数ある、または一致したセグメントが別のプロジェクトに属しています。options には一致した名前が含まれます。一致するものがない場合は、プロジェクトが使用できるすべてのセグメントが含まれます。
CONTEXT_FIELD_NOT_FOUND	プロジェクトにその名前のコンテキストフィールドがありません。大文字と小文字だけが異なる場合、ヒントには正しい名前が示されます。それ以外の場合は、フィールドを作成できる場所へのリンクが示されます。options にはプロジェクトのフィールド一覧が含まれます。
INVALID_CONSTRAINT	制約に値がないか、NUM_GT にテキストを指定する場合や、フィールドで許可されている値の範囲外を指定する場合など、Unleash がその値を受け付けません。
STRATEGY_NOT_CHOSEN	環境に複数の flexibleRollout ストラテジーがあり、strategyId が指定されていないか、strategyId がいずれにも一致しません。options には該当するストラテジーの一覧が含まれます。
STRATEGY_NOT_FOUND	strategyId がどのストラテジーにも一致せず、代わりに選択できる flexibleRollout ストラテジーも環境にありません。
STRATEGY_CONFLICT	エントリで strategyMode: "add" と strategyId の両方が設定されています。
STRATEGY_NOT_SUPPORTED	変更対象のストラテジーが flexibleRollout ストラテジーではありません。
LAST_STRATEGY_PAUSED	strategyDisabled: true を設定すると、オンのままの環境で唯一のアクティブなストラテジーが一時停止されます。最後のアクティブなストラテジーが一時停止されると、Unleash は環境をオフにします。再びオンにすると、プロジェクトのデフォルトストラテジーが追加されます。

その他のエラー：

• ツールが認識しないフィールド（スペルミスなど）には VALIDATION_ERROR が発生するため、無視されることはありません。
• フラグがプロジェクトにない場合は HTTP_404 が発生します。ヒントには create_flag と search_flags が示されます。
• 保存が途中で失敗した場合、エラーには Unleash のコードが保持され、failedEnvironment、保存またはレビューに送信された環境を示す applied、および notChanged が追加されます。

ターゲティングの作成

create_targeting ツールは、set_flag_rollout のターゲット設定に使用するコンテキストフィールドとセグメントを作成します。コンテキストフィールドはセグメントより先に作成されるため、1 回の呼び出しで、あるフィールドを条件にするセグメントとそのフィールドを作成できます。

デフォルトではすべてプロジェクトに属します。scope: "global" を指定するとすべてのプロジェクトで使用できるようになりますが、projectId とは併用できません。プロジェクトのコンテキストフィールドには Unleash 7.4.1 以降が必要です。コンテキストフィールド名とセグメント名は、インスタンス全体で一意です。

すべての名前と制約が検証されるまで、何も作成されません。その後、各項目はそれぞれ個別の API 呼び出しで作成され、ロールバックは行われません。途中で失敗すると呼び出しは停止し、エラーには created、失敗した項目を示す failed、および notAttempted が列挙されます。

パラメーター

• projectId（任意）：作成する項目の所有プロジェクトです（デフォルトは UNLEASH_DEFAULT_PROJECT）。
• scope（任意）："project"（デフォルト）または "global" です。
• contextFields（任意）：フィールドの一覧です。各フィールドには name、description、legalValues、stickiness、sortOrder を指定します。名前は URL で使用できる形式で、100 文字以内です。
• segments（任意）：セグメントの一覧です。各セグメントには name、description、constraints を指定します（形式は set_flag_rollout と同じです）。

使用例

ツールのペイロード

{
  "projectId": "ecommerce",
  "contextFields": [{ "name": "plan" }],
  "segments": [
    {
      "name": "enterprise customers",
      "constraints": [{ "contextName": "plan", "operator": "IN", "values": ["enterprise"] }]
    }
  ]
}

ツールの出力

scope、project（プロジェクトスコープの場合）、およびコンテキストフィールドとセグメントの一覧である created が含まれます。一覧の各項目には kind と name が含まれます。

エラー

リクエストに問題がある場合は、何も作成されません。エラーコードはINVALID_TARGETINGで、problemsにはすべての問題がまとめて列挙されます。それぞれの問題には、該当する項目のkindとname、コード、メッセージ、ヒント、および該当する場合は有効なoptionsが含まれます。

コード	発生条件
DUPLICATE_NAME	同じコンテキストフィールド名またはセグメント名が複数回指定されています。
CONTEXT_FIELD_EXISTS	その名前のコンテキストフィールドが、いずれかのプロジェクトに存在します。メッセージには、どのプロジェクトが所有しているかが示されます。
SEGMENT_EXISTS	その名前のセグメントが、いずれかのプロジェクトに存在します。
CONTEXT_FIELD_NOT_FOUND	セグメントの制約で指定されたフィールドが存在せず、同じ呼び出しでも作成されていません。別のプロジェクトがその名前を所有している場合は、ヒントにその旨が示されます。optionsには、そのセグメントで使用できるフィールドが列挙されます。
INVALID_CONSTRAINT	制約に値がないか、NUM_GTにテキストを指定する場合や、フィールドの許容値にない値を指定する場合など、Unleashがその値を受け付けません。

作成前に発生するその他のエラー：

• INVALID_SCOPE：scope: "global"にprojectIdが指定されています。
• PROJECT_NOT_FOUND：プロジェクトが存在しません。ヒントではlist_projectsが案内されます。
• VALIDATION_ERROR：コンテキストフィールドがUnleashの制限に違反しています。URLで使用できない名前、100文字を超える名前、250文字を超える説明、100文字を超える許容値、または重複した許容値などが該当します。
• HTTP_404：Unleashのバージョンが7.4.1より古いため、プロジェクトのコンテキストフィールドがありません。ヒントではscope: "global"が提案されます。プロジェクトのセグメントは、古いバージョンでも使用できます。

作成の途中で失敗した場合、エラーにはUnleashのコードに加えて、failed、created、notAttemptedが含まれます。

フラグの状態を取得する

get_flag_stateツールは、Unleash Admin APIからフィーチャーフラグの現在のメタデータと環境ごとのストラテジーを取得します。フラグの種類、有効／アーカイブ状態、インプレッションデータの設定、および各環境のストラテジーとバリアントを返します。

使用する場面

フラグを変更する前に確認する場合、環境全体で有効なストラテジーの数を確認する場合、またはremove_flag_strategyの呼び出しに必要なストラテジーIDを調べる場合に、このツールを使用します。

パラメーター

• featureName（必須）：フィーチャーフラグ名。
• projectId（任意）：プロジェクトID（デフォルトはUNLEASH_DEFAULT_PROJECT）。
• environment（任意）：結果を単一の環境に絞り込みます（大文字と小文字は区別されません）。
• includeSegments（任意）：一致する環境のストラテジーが使用するセグメントも返します。
• includeContextFields（任意）：フラグのプロジェクト内の制約で使用できるコンテキストフィールドも返します。

使用例

エージェントプロンプト

Use get_flag_state with:
- featureName: "new-checkout-flow"
- environment: "production"

ツールのペイロード

{
  "featureName": "new-checkout-flow",
  "projectId": "ecommerce",
  "environment": "production"
}

ツールの出力

すべての環境とストラテジーの詳細を含むフィーチャーオブジェクト全体、一致する環境、UIおよびAPIへのリンクを含むJSONオブジェクトを返します。

ストラテジーでは、セグメントはIDのみで示されます。一致する環境でセグメントが使用されている場合、出力にはそのセグメント名を示すhintが含まれます。includeSegmentsを指定すると、代わりにsegmentsが含まれます。各セグメントには、id、name、description、project、および対象に含めるユーザーを決定するconstraintsが含まれます。取得できなかったセグメントは、それぞれUnleashが返したerrorとともにsegmentErrorsに列挙されますが、呼び出し自体は失敗しません。

includeContextFieldsを指定すると、ルートのコンテキストフィールドとプロジェクト固有のコンテキストフィールドを含むcontextFieldsが出力されます。各フィールドには、name、description、legalValues、ロールアウトのstickinessを設定できるかどうか、およびプロジェクト固有の場合は所属するprojectが含まれます。

Evaluate flag

evaluate_flag ツールは、Unleash playground API を使用して、環境内の Unleash コンテキストに対する単一のフィーチャーフラグを評価します。コンテキストに対してフラグが有効かどうか、解決されたバリアント、および一致しなかった制約とセグメントを示す戦略ごとの内訳を返します。プロジェクトはフラグ名から特定されます。

Alpha： このツールは POST /api/admin/playground/features/{featureName} を使用します。これは変更される可能性のあるアルファ版の Unleash API です。このエンドポイントを提供する Unleash のバージョンが必要です。

使用する場面

「ユーザー asdf に対して show-new-checkout は有効ですか？」のような質問への回答や、特定のユーザーに対してフラグが無効になっている理由のデバッグに使用します。フラグの設定を調べるには、代わりに get_flag_state を使用してください。

パラメーター

• featureName（必須）：フィーチャーフラグ名。
• environment（任意）：評価する環境（デフォルトは UNLEASH_DEFAULT_ENVIRONMENT。設定されていない場合は必須）。
• context（任意）：フラットな Unleash コンテキストオブジェクト。userId、sessionId、remoteAddress、currentTime、appName は標準フィールドとして送信されます。それ以外のキー（例：tier）はカスタムコンテキストプロパティとして送信されます。数値とブール値は文字列に変換されます。ネストされた properties オブジェクトも使用できます。
• appName（任意）：コンテキストのアプリケーション名（デフォルト：unleash-mcp）。

使用例

エージェントのプロンプト

Use evaluate_flag to check whether "show-new-checkout" is enabled in production
for userId "asdf" on the "top" tier.

ツールのペイロード

{
  "featureName": "show-new-checkout",
  "environment": "production",
  "context": { "userId": "asdf", "tier": "top" }
}

ツールの出力

結果（ENABLED、DISABLED、またはカスタム戦略を評価できない場合は UNKNOWN）、バリアント、環境内でフラグが無効になっている場合や依存関係が満たされていない場合の警告、各戦略の結果と一致しなかった制約およびセグメント、送信されたコンテキスト、Unleash Admin UI 内のフラグへのリンクを含むテキスト概要を返します。構造化出力には、playground のレスポンス全体が含まれます。

Get flag history

get_flag_history ツールは、Unleash イベントログからフィーチャーフラグの最新の変更イベントを新しい順に取得します。各イベントの変更前と変更後のペイロード全体を返す代わりに、ツール内で構造的な差分を計算し、変更されたフィールドのみを返します。そのため、エージェントは大きなオブジェクトを比較せずに変更内容を把握できます。

使用する場面

フラグを編集または切り替える前に最近の変更内容と変更者を確認するときや、フラグが現在の状態になっている理由を説明するときに使用します。現在の設定だけでは質問への回答が得られない場合は、get_flag_state と組み合わせてください。

パラメーター

• featureName（必須）：フィーチャーフラグ名。
• limit（任意）：返す最新の変更数（1～100、デフォルト：20）。

使用例

エージェントのプロンプト

Use get_flag_history with:
- featureName: "new-checkout-flow"
- limit: 10

ツールのペイロード

{
  "featureName": "new-checkout-flow",
  "limit": 10
}

ツールの出力

featureName、フラグの記録上のすべての変更数を示す total、および events を含む JSON オブジェクトを返します。各イベントには createdAt、createdBy、type、environment、changes が含まれます。changes は、path（例：["parameters", "rollout"]）、before、after を含む、変更されたリーフのリストです。追加されたフィールドでは before: undefined、削除されたフィールドでは after: undefined になります。createdAt や lastSeenAt のように、それ自体が変更されるフィールドは差分から除外されます。環境の有効化や無効化など、ペイロードのないイベントでは changes リストは空になり、その内容は type で示されます。total が返されたイベント数より大きい場合は、limit を引き上げてください。

List flags

list_flags ツールは、プロジェクト内のフィーチャーフラグを列挙し、ページネーションとソート順を含む構造化された一覧を返します。有効なフラグとアーカイブ済みのフラグは分けて返されます。監査ワークフロー用に一覧を揃えるには、archived: false（デフォルト）と archived: true を指定して、それぞれ一度ずつ呼び出してください。

使用する場面

エージェントが既存のフラグを把握する必要がある場合に、このツールを使用します。たとえば、プロジェクトの監査、削除候補の特定、フラグの作成やラップの前のコンテキスト構築に役立ちます。これは、エージェントから呼び出せる unleash://projects/{projectId}/feature-flags リソースの相当機能です（MCP resourcesを参照）。

パラメーター

• projectId（省略可）：フラグを一覧表示するプロジェクトです（デフォルトは UNLEASH_DEFAULT_PROJECT。プロジェクトが1つだけの場合は自動的に解決されます）。
• archived（省略可）：アクティブなフラグの代わりにアーカイブ済みフラグを一覧表示する場合は true を指定します。デフォルトは false です。アクティブなフラグとアーカイブ済みフラグを同じレスポンスで取得することはできません。
• limit（省略可）：1ページあたりの最大フラグ数です（デフォルトはサーバーのページサイズで、通常は50です）。
• order（省略可）：フラグ名による並べ替え順で、asc または desc を指定します（デフォルトは asc です）。
• offset（省略可）：ページネーションでスキップするフラグ数です（デフォルトは0です）。

使用例

エージェントプロンプト

Use list_flags with:
- projectId: "ecommerce"
- archived: false

ツールペイロード

{
  "projectId": "ecommerce",
  "archived": false,
  "limit": 50,
  "order": "asc"
}

ツール出力

projectId、archived、order、limit、offset、nextOffset、totalFlags、および flags 配列を含む JSON オブジェクトを返します。各フラグには名前、タイプ、プロジェクト、アーカイブ状態、リンクが含まれます。大規模なプロジェクトをページ分割するには nextOffset を使用します。

フラグを検索する

search_flags ツールは、名前または説明の一部を指定して、すべてのプロジェクトにあるアクティブなフィーチャーフラグを検索します。フラグの完全な名前を指定すると、そのフラグと所属プロジェクトを返します。所属プロジェクトは、他のフラグツールで projectId として必要になります。

パラメーター

• query（必須）：フラグ名または説明の一部、あるいはフラグの完全な名前です。

ツール出力

一致したフラグの数を示す total と flags を含む JSON オブジェクトを返します。各フラグには、名前、プロジェクト、タイプ、説明、古くなっているかどうか、各環境で有効かどうかが含まれます。total が返されたフラグ数を上回る場合は、検索結果を絞り込むために、より長いクエリを指定してください。

プロジェクトを一覧表示する

list_projects ツールは、設定されたトークンで利用できる Unleash プロジェクトを、ページネーションと並べ替え順を指定して一覧表示します。

使用する場面

対象のプロジェクトが不明な場合や、フラグの一覧表示または作成の前にエージェントがプロジェクトを選ぶ必要がある場合に、このツールを使用します。これは、エージェントから呼び出せる unleash://projects リソースの相当機能です（MCP resourcesを参照）。

パラメーター

• limit（省略可）：1ページあたりの最大プロジェクト数です（デフォルトはサーバーのページサイズで、通常は20です）。
• order（省略可）：プロジェクトの作成日時による並べ替え順で、asc または desc を指定します（デフォルトは desc で、新しい順です）。
• offset（省略可）：ページネーションでスキップするプロジェクト数です（デフォルトは0です）。

使用例

エージェントプロンプト

Use list_projects to see which projects are available.

ツールペイロード

{
  "limit": 20,
  "order": "desc"
}

ツール出力

order、limit、offset、nextOffset、totalProjects、および projects 配列を含む JSON オブジェクトを返します。各プロジェクトには、ID、名前、説明、作成日時、URLが含まれます。

フラグ環境を切り替える

toggle_flag_environment ツールは、特定の環境でフィーチャーフラグを有効または無効にします。段階的なロールアウトを行う場合は、有効化する前に set_flag_rollout でストラテジーを設定してください。

使用する場面

ロールアウトストラテジーを設定した後にフラグを有効にする場合や、インシデント発生時またはロールアウト完了後にフラグを無効にする場合に、このツールを使用します。

パラメーター

• featureName（必須）：フィーチャーフラグの名前です。
• environment（必須）：切り替える環境です（例："production"）。
• enabled（必須）：有効にする場合は true、無効にする場合は false を指定します。
• projectId（省略可）：プロジェクトIDです（デフォルトは UNLEASH_DEFAULT_PROJECT）。

使用例

エージェントプロンプト

Use toggle_flag_environment with:
- featureName: "new-checkout-flow"
- environment: "production"
- enabled: true

ツールペイロード

{
  "featureName": "new-checkout-flow",
  "environment": "production",
  "enabled": true,
  "projectId": "ecommerce"
}

ツール出力

新しい有効状態、更新されたフィーチャーオブジェクト、および Unleash Admin UI と Admin API におけるフラグへのリンクを含む JSON オブジェクトを返します。

フラグストラテジーを削除する

remove_flag_strategy ツールは、フィーチャーフラグ環境からストラテジー設定を削除します。ストラテジーIDを確認するには、まず get_flag_state を使用してください。

使用するタイミング

古くなったストラテジーを整理するときや、set_flag_rollout では変更できないストラテジー（flexibleRollout ではないもの）を削除し、再度 set_flag_rollout を呼び出して置き換えるときに、このツールを使用します。

パラメーター

• featureName（必須）：フィーチャーフラグ名。
• environment（必須）：ストラテジーを削除する環境。
• strategyId（必須）：削除するストラテジーの ID（get_flag_state で確認します）。
• projectId（任意）：プロジェクト ID（デフォルトは UNLEASH_DEFAULT_PROJECT）。

使用例

エージェントのプロンプト

Use get_flag_state to find strategy IDs for "new-checkout-flow" in production,
then use remove_flag_strategy to delete the old strategy.

ツールのペイロード

{
  "featureName": "new-checkout-flow",
  "environment": "production",
  "strategyId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "projectId": "ecommerce"
}

ツールの出力

削除されたストラテジー ID、環境内に残っているストラテジー数、更新されたフィーチャーオブジェクト、および Unleash Admin UI と Admin API 内のフラグへのリンクを含む JSON オブジェクトを返します。

フラグのライフサイクルを更新する

update_flag_lifecycle ツールは、フィーチャーフラグをライフサイクルの各段階へ移行させます。Unleash は SDK のメトリクスから initial、pre-live、live の各段階を設定するため、このツールで変更できるのは API で許可されている操作のみです。つまり、完了、アーカイブ、それぞれの取り消し、および古いフラグのマーカーです。

使用するタイミング

フラグの役目が終わったときに、このツールを使用します。推奨される順序は、complete を実行し、次に cleanup_flag でコードからフラグを削除してから、archive を実行することです。

パラメーター

• featureName（必須）：フィーチャーフラグ名。
• action（必須）：次のいずれかです。
  • complete：フラグを完了済みとしてマークします。status が必要です。
  • uncomplete：complete を取り消します。
  • archive：フラグをアーカイブし、SDK に配信されないようにします。他のフラグが依存している場合は拒否されます。
  • revive：アーカイブ済みのフラグを復元します。
  • mark_stale / unmark_stale：段階とは独立した古いフラグのマーカーを設定または解除します。
• status（complete の場合は必須）：フィーチャーを製品に残す場合は "kept"、削除した場合は "discarded" を指定します。
• statusValue（任意）：complete の詳細です。たとえば、残されたバリアントを指定します。
• projectId（任意）：プロジェクト ID。省略すると、フラグ名はプロジェクト間で一意であるため、ツールがフラグ名からプロジェクトを特定します。

使用例

エージェントのプロンプト

The new checkout flow is fully rolled out. Mark "new-checkout-flow" as completed and kept.

ツールのペイロード

{
  "featureName": "new-checkout-flow",
  "action": "complete",
  "status": "kept",
  "projectId": "ecommerce"
}

ツールの出力

changed、呼び出し前後のフラグのライフサイクル状態 before と after、1 行の summary、および次に呼び出すツールを示す help を含む JSON オブジェクトを返します。フラグが completed または archived に達すると、help は preservePath に完了状態を設定して cleanup_flag を呼び出すよう提案します（kept の場合は有効なパスを保持し、discarded の場合は無効なパスを保持します）。フラグがすでに指定された状態の場合、changed は false となり、変更は行われません。

プロジェクト設定を更新する

update_project_settings ツールは、プロジェクト内のフラグの設定方法を変更します。各環境のデフォルトストラテジー、デフォルトのスティッキネス、およびプロジェクトに含まれる環境を変更できます。環境のデフォルトストラテジーは、その環境にストラテジーがないフラグを有効にしたときと、すべてのストラテジーが一時停止中のフラグ（既存のフラグも含む）を toggle_flag_environment で有効にしたときに、Unleash が追加するストラテジーです。

使用するタイミング

ユーザーがプロジェクトのデフォルト設定を変更したいときに、このツールを使用します。環境は追加できますが、削除することはできません。

パラメーター

• projectId（任意）：プロジェクト ID。指定がない場合は UNLEASH_DEFAULT_PROJECT にフォールバックします。
• defaultStickiness（任意）：ユーザーを同じバケットに維持するコンテキストフィールドです。例：sessionId。Unleash Enterprise が必要です。オープンソース版の Unleash には、この設定用のエンドポイントがありません。
• addEnvironments（任意）：プロジェクトで利用できるようにする、既存の環境名です。
• defaultStrategies（任意）：環境ごとに、rolloutPercentage、名前で指定する segments、constraints、stickiness、groupId、title、variants を設定します。省略したフィールドは現在の値を維持し、[] を指定すると segments、constraints、variants がクリアされます。新しいデフォルトでは、各フラグにそれぞれ独自の groupId が割り当てられます。

3 つの設定のうち、少なくとも 1 つが必須です。すべての名前とバリアントの検証が完了するまで変更は適用されません。また、現在のデフォルトが flexibleRollout 戦略でない場合は、置き換えずに拒否されます。まずデフォルトのスティッキネスを設定するため、オープンソース版の Unleash では何も変更される前に呼び出しが失敗します。次に環境を追加し、その後デフォルト戦略を設定します。ロールバックはありません。手順が失敗すると、エラーには入力と同じ形式で applied、failed、notApplied が返されます。設定を読み戻す処理だけが失敗した場合、エラーには applied が返され、設定を再送信しないように示されます。オープンソース版の Unleash では、defaultStickiness は failed ではなく notSupported に含まれます。すでに一致している設定は再書き込みされないため、同じ呼び出しを繰り返しても監査イベントは追加されません。また、制約はインスタンスの上限に照らして検証されます。

使用例

エージェントへのプロンプト

Flags turned on in production of ecommerce should start at 10% for the beta-users segment.

ツールのペイロード

{
  "projectId": "ecommerce",
  "defaultStrategies": [
    { "environment": "production", "rolloutPercentage": 10, "segments": ["beta-users"] }
  ]
}

ツールの出力

applied、すでに一致していた設定を示す unchanged、プロジェクトの defaultStickiness、および各環境の defaultStrategy を含む JSON オブジェクトを返します。変更された設定については、以前の値も previous として含まれます。変更リクエストがオフになっている環境が追加された場合は、その旨を示す注記が返されます。

フラグのクリーンアップ

cleanup_flag ツールは、望ましいコードパスを維持しながら、コードベースからフィーチャーフラグのコードを安全に削除するための手順を段階的に生成します。

使用するタイミング

フィーチャーフラグのライフサイクルが完了したときに、このツールを使用します。

• ロールアウトが 100% に達し、フラグが不要になった後。
• 実験的な機能を非推奨にするとき（無効なパスを維持します）。
• 不要になったキルスイッチを削除するとき。
• 古いフラグに関する技術的負債を解消するとき。

仕組み

このツールは、LLM に次の手順を案内する包括的なクリーンアップ手順を返します。

1. grep パターンを使って、フラグのすべての出現箇所を特定します。
2. 使用パターン（if-else ブロック、三項式、ガード節、フック、デコレーター、ミドルウェア）を特定します。
3. 正しいコードパスを維持しながら、フラグのチェックを削除します。
4. 言語固有のガイダンスに従って、未使用のインポートを整理します。
5. クリーンアップ後の検索とテストの手順で、変更を検証します。

preservePath が指定されていない場合、処理を進める前にどちらのパスを残すかユーザーに確認するよう案内します。

パラメーター

• flagName（必須）：削除するフィーチャーフラグの名前（例："new-checkout-flow"）。
• preservePath（任意）：フラグが有効なときのコードパスを残す場合は "enabled"（ロールアウト完了時に一般的です）、フラグが無効なときのパスを残す場合は "disabled"（削除する実験機能に使用します）。省略した場合は、ツールからユーザーに確認するよう求められます。
• files（任意）：クリーンアップする特定のファイルです。省略した場合、コードベース全体を検索します。
• language（任意）：インポートのクリーンアップに関する特別なガイダンスに使用するプログラミング言語です（例："typescript"、"python"）。指定がない場合は、files から自動検出されます。

使用例

エージェントへのプロンプト

Use cleanup_flag with:
- flagName: "new-checkout-flow"
- preservePath: "enabled"

ツールのペイロード

{
  "flagName": "new-checkout-flow",
  "preservePath": "enabled",
  "files": ["src/components/checkout.tsx", "src/api/checkout.ts"],
  "language": "typescript"
}

ツールの出力

クリーンアップの範囲と維持するパス、すべての出現箇所を見つける grep コマンド、パターンごとの削除手順、言語固有のインポート整理、クリーンアップ後の検証手順（再検索、テストの実行、手動レビュー）を記載した Markdown ガイドを返します。

フィードバックを送信する

send_feedback ツールは、この MCP が期待に応えられなかった状況を報告します。報告は Unleash がホストするインスタンスに送信され、修正や新しいツールの優先順位付けに役立てられます。

使用するタイミング

次のいずれかが発生した場合、アシスタントはユーザーに返信する前にこのツールを呼び出してください。

• tool_error：ツールの呼び出しでエラーが返された場合（認証エラーである HTTP 401 または 403 を除く）。
• unsupported_action：どのツールでも対応できないことをユーザーが依頼した場合。
• unexpected_result：ツールの呼び出しは成功したものの、期待した結果ではなかった場合。

ツールの呼び出しが成功した後には絶対に呼び出さないでください。また、send_feedback 自体の失敗を報告するためにも呼び出さないでください。

同意

ユーザーが同意するまで、何も送信されません。最初の呼び出し時に、MCP は MCP の elicitation プロンプトを通じてユーザーに確認し、回答を feedback_consent.json に保存します。そのため、質問は一度だけ行われます。このファイルは、プラットフォームの設定ディレクトリに保存されます。

• XDG_CONFIG_HOME が設定されている場合（すべてのプラットフォーム）：$XDG_CONFIG_HOME/unleash-mcp/feedback_consent.json
• macOS：~/Library/Application Support/unleash-mcp/feedback_consent.json
• Linux：~/.config/unleash-mcp/feedback_consent.json
• Windows：%APPDATA%\unleash-mcp\feedback_consent.json（または APPDATA が設定されていない場合は ~\AppData\Roaming\unleash-mcp\feedback_consent.json）

ファイルを別のディレクトリに保存するには、UNLEASH_MCP_CONFIG_DIR を設定してください。再度確認するには、ファイルを削除してください。

ユーザーが同意しない場合、ツールはフィードバックが無効であることを示すメッセージを返します。この場合、アシスタントはそのセッション中に再度呼び出してはいけません。クライアントが elicitation に対応していない場合、プロンプトがキャンセルされた場合、または60秒以内に回答がなかった場合、現在のセッションではフィードバックが無効になり、何も保存されません。そのため、次のセッションで再度確認されます。

プロンプトを表示せずに同意または拒否するには、UNLEASH_MCP_SEND_FEEDBACK=true または UNLEASH_MCP_SEND_FEEDBACK=false を設定します。この環境変数は同意ファイルより優先されます。elicitation に対応していないクライアントや CI 環境で役立ちます。この方法で同意が拒否された場合、send_feedback ツールはツール一覧から除外され、サーバーの指示にも記載されません。そのため、アシスタントが呼び出そうとすることはありません。

OpenCode と Google Gemini または Antigravity では、ユーザーにプロンプトが表示されません（OpenCode は自動で同意し、Antigravity はキャンセルします）。これらのクライアント、および名前を報告しないクライアントでは、保存済みの同意がユーザーによるものとは限らないため、サーバーはプロンプトを省略し、同意ファイルも無視します。UNLEASH_MCP_SEND_FEEDBACK=true が設定されていない限り、フィードバックは無効のままです。それ以外のクライアントでは、同意ファイルに保存された選択が使用されます。

サーバーが createMcpHandler を通じて HTTP ホストに組み込まれている場合、ホストが feedbackConsent を渡さない限り、同意はデフォルトで拒否されます。そのため、send_feedback はデフォルトではリモートクライアントに公開されません。

記録される内容

許可リストに登録された項目のみが送信されます。

• 問題の種類、ツール名、正規化されたエラーコード。
• MCP のバージョン、クライアント名、クライアントのバージョン。
• アシスタントが提供する短い概要。

概要にフラグ名、プロジェクト ID、コード、URL、トークンを含めてはいけません。生のエラーメッセージが送信されることはありません。

パラメーター

• issueType（必須）：tool_error、unsupported_action、または unexpected_result。
• summary（必須）：発生した問題、または依頼された内容を説明する1～2文（最大500文字）。
• tool（任意）：関連する MCP ツールの名前（例：create_flag）。対応できない依頼の場合は省略します。
• errorCode（任意）：失敗したツールの結果から得られる正規化されたエラーコード（例：HTTP_500 または VALIDATION_ERROR）。

使用例

エージェントのプロンプト

The set_flag_rollout call failed with HTTP_500. Use send_feedback to report it,
then tell me what happened.

ツールのペイロード

{
  "issueType": "tool_error",
  "tool": "set_flag_rollout",
  "errorCode": "HTTP_500",
  "summary": "Configuring a gradual rollout failed with a server error even though the flag exists in the environment."
}

ツールの出力

success、sent、dryRun、およびフィードバックを送信した（または --dry-run モードで送信する）ことを確認する message、あるいはユーザーが同意していないためフィードバックが無効であることを示す message を含む JSON オブジェクトを返します。

MCP リソース

サーバーは、プロジェクトとフィーチャーフラグのデータを読み取るための MCP リソースを登録します。すべてのリソースは JSON を返し、60 秒間キャッシュされます。

URI テンプレート	説明
unleash://projects{?limit,order,offset}	プロジェクトを一覧表示します。デフォルトのページサイズは 20 で、作成日時の新しい順に並びます。
unleash://projects/{projectId}/feature-flags{?limit,order,offset}	プロジェクト内のフラグを一覧表示します。デフォルトのページサイズは 50 で、アルファベット順に並びます。
unleash://projects/{projectId}/feature-flags/{flagName}	単一のフィーチャーフラグのメタデータです。

最初の 2 つのテンプレートでは、オプションのクエリパラメーター limit（ページサイズ）、order（asc または desc）、offset（ページネーションの開始位置）を指定できます。レスポンスには、fetchedAt、cached、totalProjects または totalFlags、nextOffset の各フィールドが含まれます。

リソースとツールの違い： MCP リソースはアプリケーションによって制御されるため、多くのクライアントではユーザー操作が必要な UI（たとえば # メンション）でのみ表示され、エージェントが独自に resources/read を呼び出すことはできません。エージェントがプログラムでプロジェクトやフラグを列挙する必要がある場合は、同じデータをツールインターフェース経由で返す list_projects と list_flags ツールを使用してください。detect_flag のインベントリ分析も同じ経路を使用します。

リソース読み取りの例

Read unleash://projects/ecommerce/feature-flags?limit=10&order=asc

ecommerce プロジェクト内の最初の 10 個のフィーチャーフラグを、アルファベット順でページネーションのメタデータとともに返します。

アーキテクチャ

このサーバーは、目的に特化した設計を採用しています。

構成

src/
├── index.ts                     # Stdio CLI entry point
├── server.ts                    # Transport-agnostic server factory
├── remote.ts                    # HTTP request handler for embedded mode
├── config.ts                    # Configuration loading and validation
├── context.ts                   # Shared runtime context
├── version.ts                   # Version constant
├── unleash/
│   ├── client.ts                # Unleash Admin API client
│   ├── attribution.ts           # Client attribution for outbound headers
│   └── feedbackHttpClient.ts    # send_feedback transport
├── http/
│   └── httpClient.ts            # Generic fetch wrapper for API clients
├── feedback/
│   ├── consentDecision.ts       # granted | denied consent type
│   ├── consentResolver.ts       # Resolves send_feedback consent (env, file, prompt)
│   ├── consentStore.ts          # Persists consent in feedback_consent.json
│   └── elicitation.ts           # MCP elicitation prompt asking the user once
├── tools/
│   ├── types.ts                 # Shared ToolDefinition type
│   ├── createFlag.ts            # create_flag tool
│   ├── evaluateChange.ts        # evaluate_change tool
│   ├── detectFlag.ts            # detect_flag tool
│   ├── wrapChange.ts            # wrap_change tool
│   ├── cleanupFlag.ts           # cleanup_flag tool
│   ├── constraints.ts           # Constraint schema and checks shared by set_flag_rollout and create_targeting
│   ├── createTargeting.ts       # create_targeting tool
│   ├── setFlagRollout.ts        # set_flag_rollout tool
│   ├── getFlagState.ts          # get_flag_state tool
│   ├── listFlags.ts             # list_flags tool
│   ├── listProjects.ts          # list_projects tool
│   ├── searchFlags.ts           # search_flags tool
│   ├── evaluateFlag.ts          # evaluate_flag tool
│   ├── getFlagHistory.ts        # get_flag_history tool
│   ├── toggleFlagEnvironment.ts # toggle_flag_environment tool
│   ├── removeFlagStrategy.ts    # remove_flag_strategy tool
│   ├── updateFlagLifecycle.ts   # update_flag_lifecycle tool
│   ├── updateProjectSettings.ts # update_project_settings tool
│   └── sendFeedback.ts          # send_feedback tool
├── resources/
│   └── unleashResources.ts      # MCP resource handlers (projects, flags)
├── prompts/
│   └── promptBuilder.ts         # Markdown formatting utilities
├── evaluation/
│   ├── riskPatterns.ts          # Risk assessment patterns
│   └── flagDetectionPatterns.ts # Parent flag detection patterns
├── detection/
│   ├── flagDiscovery.ts         # Flag discovery strategies
│   └── flagScoring.ts           # Scoring and ranking logic
├── knowledge/
│   └── unleashBestPractices.ts  # Best practices knowledge base
├── templates/
│   ├── languages.ts             # Language detection and metadata
│   ├── wrapperTemplates.ts      # Code wrapping templates
│   ├── searchGuidance.ts        # Pattern search instructions
│   └── cleanupGuidance.ts       # Flag cleanup instructions
└── utils/
    ├── errors.ts                # Error normalization
    ├── streaming.ts             # Progress notifications
    ├── toolResult.ts            # JSON tool results
    ├── showsElicitationForms.ts # Clients whose elicitation forms never reach the user
    └── stdioLogging.ts          # Stdio protocol traffic logging

設計原則

• シンプルなインターフェース：中核機能に必要なエンドポイントのみを提供します。
• 目的に特化：各モジュールは、明確に定義された特定の目的を果たします。
• 明示的な検証：API 呼び出しの前に、すべての入力を Zod スキーマで検証します。
• エラーの標準化：すべてのエラーを {code, message, hint} 形式に変換します。
• 進行状況のストリーミング：時間のかかる操作の進行状況を確認できます。
• ベストプラクティスの統合：Unleash ドキュメントのガイダンスをツールの説明に組み込んでいます。

設定

このセクションでは、すべての設定オプションを簡単に確認できます。

環境変数：

• UNLEASH_BASE_URL：Unleash インスタンスの URL（必須）。https://your-instance.getunleash.io と https://your-instance.getunleash.io/api のどちらも受け付けます。末尾に /api がある場合、サーバーはこれを取り除くため、ほとんどの Unleash SDK が想定する値をそのまま貼り付けられます。
• UNLEASH_PAT：個人用アクセストークン（必須）。
• UNLEASH_DEFAULT_PROJECT：MCP が使用するデフォルトのプロジェクト ID（任意）。
• UNLEASH_MCP_SEND_FEEDBACK：プロンプトを表示せずに send_feedback の同意を許可または拒否するには、true または false を指定します（任意）。保存済みの同意ファイルより優先されます。
• UNLEASH_FEEDBACK_URL：send_feedback のレポートを受け取る Unleash インスタンスのベース URL（任意）。デフォルトでは Unleash がホストする本番インスタンスが使用されます。
• UNLEASH_MCP_CONFIG_DIR：feedback_consent.json を格納するディレクトリ（任意）。デフォルトでは、同意で説明するプラットフォームの設定ディレクトリが使用されます。

CLI フラグ：

• --dry-run：実際の API 呼び出しを行わずに操作をシミュレートします。
• --log-level：ログの詳細度を設定します（debug、info、warn、error）。

ベストプラクティス

このサーバーでは、公式ドキュメントに基づく Unleash のベストプラクティスを推奨しています。

フラグのライフサイクル

1. 意図を持って作成する：目的が伝わるように、適切なフラグの種類を選びます。
2. 明確に記述する：「なぜ」必要なのかを説明する説明文を書きます。
3. 削除を計画する：フィーチャーフラグは一時的なものです。削除を計画してください。
4. 使用状況を監視する：重要なフラグではインプレッションデータを有効にします。

フラグの種類

• リリースフラグ：機能を段階的に展開するために使用します（全体への展開後に削除してください）。
• 実験フラグ：A/B テストに使用します（分析後に削除してください）。
• 運用フラグ：システムの動作を制御します（長期間使用し、定期的に見直してください）。
• キルスイッチ：緊急時の制御に使用します（機能が安定するまで維持してください）。
• 権限フラグ：アクセス制御に使用します（長期間使用し、権限を見直してください）。

命名規則

• ケバブケースを使用します：new-checkout-flow
• 内容がわかる名前にします：flag1 ではなく enable-ai-recommendations。
• 必要に応じて対象範囲を含めます：mobile-push-notifications。

API リファレンス

このサーバーは Unleash Admin API を使用します。API の詳細については、以下を参照してください。

• Unleash Admin API OpenAPI 仕様
• Unleash API ドキュメント

使用するエンドポイント

• GET /api/admin/projects - プロジェクトを一覧表示
• GET /api/admin/projects/{projectId}/features - フィーチャーフラグを一覧表示
• POST /api/admin/projects/{projectId}/features - フィーチャーフラグを作成
• GET /api/admin/projects/{projectId}/features/{featureName} - フラグの詳細を取得
• GET /api/admin/segments/{id} - セグメントを取得
• POST /api/admin/segments - セグメントを作成
• GET /api/admin/context - グローバルコンテキストフィールドを一覧表示
• GET /api/admin/context/{name} - コンテキストフィールドを取得
• POST /api/admin/context - グローバルコンテキストフィールドを作成
• GET /api/admin/projects/{projectId}/context - プロジェクトのコンテキストフィールドを一覧表示
• POST /api/admin/projects/{projectId}/context - プロジェクトのコンテキストフィールドを作成
• GET /api/admin/projects/{projectId}/overview - プロジェクトの設定とデフォルト戦略を取得
• PUT /api/admin/projects/{projectId} - プロジェクトのデフォルトのスティッキネスを設定（Enterprise のみ）
• GET /api/admin/environments - 環境を一覧表示
• POST /api/admin/projects/{projectId}/environments - 環境をプロジェクトに追加
• POST /api/admin/projects/{projectId}/environments/{environment}/default-strategy - 環境のデフォルト戦略を設定
• GET /api/admin/search/features - フィーチャーフラグを検索
• GET /api/admin/search/events - フィーチャーフラグの変更イベントを取得
• POST /api/admin/projects/{projectId}/features/{featureName}/environments/{environment}/strategies - ロールアウト戦略を追加
• DELETE /api/admin/projects/{projectId}/features/{featureName}/environments/{environment}/strategies/{strategyId} - 戦略を削除
• POST /api/admin/projects/{projectId}/features/{featureName}/environments/{environment}/on - フラグを有効化
• POST /api/admin/projects/{projectId}/features/{featureName}/environments/{environment}/off - フラグを無効化
• POST /api/admin/projects/{projectId}/features/{featureName}/lifecycle/complete - フラグを完了にする
• POST /api/admin/projects/{projectId}/features/{featureName}/lifecycle/uncomplete - フラグを未完了に戻す
• POST /api/admin/projects/{projectId}/archive/validate - アーカイブ前に依存関係を確認
• DELETE /api/admin/projects/{projectId}/features/{featureName} - フラグをアーカイブ
• POST /api/admin/archive/revive/{featureName} - アーカイブ済みのフラグを復元
• POST /api/admin/projects/{projectId}/stale - フラグを古い状態、または古くない状態としてマーク
• GET /api/admin/projects/{projectId}/change-requests/config - 承認が必要な環境を確認
• GET /api/admin/user - 変更リクエストをスキップできるか確認
• GET /api/admin/projects/{projectId}/change-requests/pending - 自分の未完了の変更リクエストと、その中で保留中の変更を確認
• POST /api/admin/projects/{projectId}/environments/{environment}/change-requests - 変更リクエストに変更を追加
• PUT /api/admin/projects/{projectId}/change-requests/{id}/changes/{changeId} - 追加待ちの戦略を変更
• PUT /api/admin/projects/{projectId}/change-requests/{id}/state - 変更リクエストをレビューに提出するか、変更を取り下げた場合にその変更リクエストをキャンセル
• DELETE /api/admin/projects/{projectId}/change-requests/{id}/changes/{changeId} - 保留中の変更を取り下げ
• DELETE /api/admin/projects/{projectId}/change-requests/{id} - 変更を取り下げた場合に下書きを削除
• GET /api/admin/ui-config - デフォルト戦略が遵守する必要のある制約とセグメントの上限を取得

send_feedback は Unleash インスタンスを呼び出しません。Unleash がホストするフィードバックインスタンスの POST {UNLEASH_FEEDBACK_URL}/feedback に送信します。

トラブルシューティング

設定の問題

エラー："UNLEASH_BASE_URL must be a valid URL"：プロトコルを含め、ベース URL が完全であることを確認してください。例：https://app.unleash-hosted.com/instance。末尾のスラッシュは削除してください。

エラー："UNLEASH_PAT is required"：.env ファイルが存在し、UNLEASH_PAT={{your-personal-access-token}} が含まれていることを確認してください。トークンが Unleash で有効であることを確認してください。

API の問題

エラー：「HTTP_401」：パーソナルアクセストークンが無効か、期限切れの可能性があります。Profile > View Profile settings > Personal API tokens > New token から新しいトークンを生成してください。

エラー：「HTTP_403」：このトークンには、このプロジェクトでフラグを作成する権限がありません。Unleash でロールと権限を確認してください。

エラー：「HTTP_404」：プロジェクト ID が存在しません。Unleash Admin UI でプロジェクト ID を確認してください。

エラー：「HTTP_409」：この名前のフラグは、プロジェクト内にすでに存在します。別の名前を使用するか、既存のフラグを再利用してください。

フィードバックの問題

「フィードバックは無効です」：ユーザーが同意を拒否した、クライアントが同意プロンプトを表示できなかった、または UNLEASH_MCP_SEND_FEEDBACK=false が設定されています。UNLEASH_MCP_SEND_FEEDBACK=true を設定するか、feedback_consent.json を削除して、再度確認を求められるようにしてください。同意を参照してください。

エラー：「Unleash フィードバックエンドポイントへの接続に失敗しました」：レポートからフィードバックインスタンスに到達できませんでした。UNLEASH_FEEDBACK_URL（またはデフォルトの本番インスタンス）にネットワークからアクセスできることを確認してください。フラグの操作には影響しません。

ライセンス

MIT

コントリビューション

このプロジェクトは、明確な目的に基づき、対象範囲を絞っています。コントリビューションは以下の条件を満たす必要があります。

• 既存のツールの範囲と MCP リソースモデルに沿っていること。
• 薄く、目的に特化したアーキテクチャを維持すること。
• Unleash のベストプラクティスに従うこと。
• 明確なドキュメントを含めること。