Octopus Deploy Official MCP Server

公式

Octopus MCP Serverは、AIアシスタントに強力なツールを提供し、Octopusインスタンス内の問題を調査、照会、診断できるようにすることで、究極のDevOpsパートナーへと変貌させます。

GitHub
98

ドキュメント

Octopus Deploy Logo

Octopus Deploy 公式 MCP サーバー

Octopus は、Kubernetes、マルチクラウド、オンプレミスインフラストラクチャ、その他あらゆる環境へのソフトウェアデリバリーを容易にします。他のツールでは実現できない規模で CD を処理できるツールを使用して、ソフトウェアと AI ワークロードのリリース、デプロイ、運用を自動化します。

Model Context Protocol (MCP) を使用すると、Claude Code や ChatGPT など、日々の業務で使用する AI アシスタントが、標準化された方法で所有するシステムやサービスに接続し、それらのシステムやサービスから情報を取得して質問に答えたり、タスクを実行したりできるようになります。

Octopus MCP サーバーは、AI アシスタントに強力なツールを提供し、Octopus インスタンス内の問題を検査、クエリ、診断できるようにすることで、AI アシスタントを究極の DevOps ウィングメイトに変えます。サポートされているユースケースとサンプルプロンプトの一覧については、ドキュメント を参照してください。

Octopus サーバーの互換性

MCP サーバーが公開するほとんどのツールは、少なくとも Octopus サーバーのバージョン 2021.1 から利用可能な安定した API を使用しています。新しいツールについては、ドキュメントでサポートされる最小バージョンが指定されます。または、コマンドライン引数 --list-tools-by-version を使用して、特定のツールが Octopus のバージョンとどのように関連しているかを確認できます。

🚀 インストール

Docker 経由でのインストール

ホストプロセスリスト (ps aux / /proc/<pid>/cmdline) で認証情報が公開されるのを避けるため、認証情報は環境変数で指定する必要があります。Octopus サーバーの URL は、引き続き --server-url フラグで指定できます。

docker run -i --rm -e OCTOPUS_API_KEY=your-key -e OCTOPUS_SERVER_URL=https://your-octopus.com octopusdeploy/mcp-server

完全な設定例 (Claude Desktop、Claude Code、Cursor 用):

{
  "mcpServers": {
    "octopus-deploy": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "OCTOPUS_SERVER_URL",
        "-e",
        "OCTOPUS_API_KEY",
        "octopusdeploy/mcp-server"
      ],
      "env": {
        "OCTOPUS_SERVER_URL": "https://your-octopus.com",
        "OCTOPUS_API_KEY": "YOUR_API_KEY"
      }
    },
  }
}

Apple Mac ユーザーの場合、Docker に Linux プラットフォームを使用させるために、設定に次の引数を追加する必要がある場合があります。

"--platform",
"linux/amd64",

これらの引数が不要になるように、ネイティブ ARM ビルドをまもなくリリースする予定です。

Node 経由でのインストール

要件

  • Node.js >= v20.0.0
  • MCP サーバーが HTTPS 経由でアクセスできる Octopus Deploy インスタンス
  • Octopus Deploy API キーまたはアクセストークン (下記の 認証 を参照)

設定

完全な設定例 (Claude Desktop、Claude Code、Cursor 用):

書き込みツール有効 (デフォルト):

{
  "mcpServers": {
    "octopusdeploy": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@octopusdeploy/mcp-server"],
      "env": {
        "OCTOPUS_SERVER_URL": "https://your-octopus.com",
        "OCTOPUS_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

読み取り専用モード (本番環境で推奨):

{
  "mcpServers": {
    "octopusdeploy": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@octopusdeploy/mcp-server", "--read-only"],
      "env": {
        "OCTOPUS_SERVER_URL": "https://your-octopus.com",
        "OCTOPUS_API_KEY": "YOUR_API_KEY"
      }
    }
  }
}

Octopus MCP サーバーは、通常、選択した AI クライアント内で設定します。

npm パッケージとしてパッケージ化され、Node の npx コマンドで実行されます。認証情報 (API キーまたはアクセストークン) は環境変数で指定する必要があり、プロセスリストでシークレットが公開されるのを避けるため、コマンドライン引数としては受け付けられません。Octopus サーバーの URL は、OCTOPUS_SERVER_URL 環境変数または --server-url フラグで指定できます。

OCTOPUS_API_KEY=API-KEY \
OCTOPUS_SERVER_URL=https://your-octopus.com \
npx -y @octopusdeploy/mcp-server

または、コマンドラインでサーバー URL を指定します:

OCTOPUS_API_KEY=API-KEY \
npx -y @octopusdeploy/mcp-server --server-url https://your-octopus.com

認証

MCP サーバーは 2 つの認証方法をサポートしています。どちらも環境変数で指定します。フラグはホストプロセスリストでローカルユーザーに表示されるため、認証情報はコマンドラインでは受け付けられません。

API キー (インタラクティブな使用に推奨)

API キーは、Octopus Deploy の標準的な認証方法です。Octopus Deploy ユーザープロファイルから生成できます。

OCTOPUS_API_KEY=API-XXXXXXXXXXXXXXXXXXXXXXXXXX \
OCTOPUS_SERVER_URL=https://your-octopus.com \
npx -y @octopusdeploy/mcp-server

アクセストークン / Bearer トークン (自動化シナリオのみ)

サーバーは、API キーの代わりに、有効期間の短いアクセストークン (Bearer トークン) もサポートしています。この認証方法は、外部システムが MCP サーバーに有効期間の短いトークンを発行する 自動化シナリオ専用 です (例: CI/CD パイプライン、自動オーケストレーション、またはマシン間ワークフロー)。有効期間の長い Bearer トークンは使用しないでください。インタラクティブなセッションや長時間実行されるセッションには、代わりに API キーを使用してください。

OCTOPUS_ACCESS_TOKEN=your-short-lived-token \
OCTOPUS_SERVER_URL=https://your-octopus.com \
npx -y @octopusdeploy/mcp-server

アクセストークンを使用した完全な設定例:

{
  "mcpServers": {
    "octopusdeploy": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@octopusdeploy/mcp-server"],
      "env": {
        "OCTOPUS_SERVER_URL": "https://your-octopus.com",
        "OCTOPUS_ACCESS_TOKEN": "YOUR_TOKEN"
      }
    }
  }
}

API キーとアクセストークンの両方が提供された場合、アクセストークンが優先されます。アクティブな認証方法はログファイル (--log-file で設定可能) に記録されるため、オペレーターはどの認証情報が使用されているかを確認できます。

設定オプション

Octopus MCP サーバーは、利用可能なツールをカスタマイズするためのいくつかのコマンドラインオプションをサポートしています。

必要なツールがわからない場合は、追加のコマンドラインオプションなしで実行し、提供されるデフォルトを使用することをお勧めします。

ツールセット

--toolsets パラメーターを使用して、特定のツールグループを有効にします:

# Enable all toolsets (default)
npx -y @octopusdeploy/mcp-server

# Enable only specific toolsets
npx -y @octopusdeploy/mcp-server --toolsets projects,deployments

# Enable all toolsets explicitly
npx -y @octopusdeploy/mcp-server --toolsets all

利用可能なツールセット:

  • core - 基本操作 (常に有効)
  • projects - プロジェクト操作
  • deployments - デプロイ操作
  • releases - リリース管理
  • runbooks - Runbook の検出と実行
  • tasks - タスク操作
  • tenants - マルチテナント操作
  • kubernetes - Kubernetes 操作
  • machines - デプロイターゲット操作
  • certificates - 証明書操作
  • accounts - アカウント操作
  • interruptions - 手動介入と承認操作
  • featureToggles - カスタマー機能トグルの検査と調整
  • context - 認証済みユーザーとプロジェクトコンテキスト (現在のユーザー、Git ブランチ)

読み取り専用モード

サーバーはデフォルトで書き込みツールが有効な状態で実行されます。--read-only を渡すと、すべての書き込みツールが無効になり、execute バックストップを介した POST/PUT/PATCH/DELETE がブロックされます。ほとんどのキュレートされたツールは既に読み取り専用です。書き込みを実行するのはごく一部のセットのみです。

書き込みが有効なツール (常時書き込み):

  • create_release - 新しいリリースを作成
  • deploy_release - リリースを環境とテナントにデプロイ
  • run_runbook - 1 つ以上の環境 (およびオプションのテナント) に対して Runbook を実行
  • update_feature_toggle - 既存の機能トグルの環境ごとの状態とロールアウト率を調整

条件付き書き込みツール: execute は構造化された REST バックストップであり、その階層 (読み取り / 書き込み / 削除) は渡される HTTP メソッドによって決まります。詳細については、API カタログとバックストップ セクションを参照してください。

書き込みツールは MCP エリシテーションプロンプトによってゲートされます。エリシテーションをサポートするクライアントは、呼び出しが続行される前に確認を求められます。エリシテーションをサポートしないクライアントは、ツール引数で confirm: true を渡す必要があります。そうしないと、ツールはエラーで中止されます。OCTOPUS_SKIP_ELICITATION=true を設定すると、ゲートを完全にバイパスします (無人自動化を目的としています)。

サーバーは、HTTP メソッドに基づいてサーバー側で強制される 3 層の読み取り/書き込み/削除分類を使用します (エージェントは意図について嘘をつくことでこれをバイパスできません):

  • read — 常に許可されます。execute を介した GET リクエスト、およびすべての find_* / get_* / list_* ツール。
  • write — execute および上記の常時書き込みツールを介した POST/PUT/PATCH。--read-only が設定されている場合はブロックされます。
  • delete — execute を介した DELETE。--allow-deletes が必要であり、--read-only が設定されている場合はブロックされます。壊滅的な削除パス (例: DELETE /api/spaces/{id}、DELETE /api/users/{id}) や API キーエンドポイントの小さなセットは、両方のフラグを無視するハードな機密拒否リストに登録されています。
# Default - write tools enabled (POST/PUT/PATCH)
npx -y @octopusdeploy/mcp-server

# Additionally permit DELETE requests through the execute tool
npx -y @octopusdeploy/mcp-server --allow-deletes

# Read-only mode - write/delete tools disabled
npx -y @octopusdeploy/mcp-server --read-only

セキュリティに関する注意: 適切な最小権限のアクセス許可を持つ API キーを使用してください。書き込み操作により、Octopus インスタンスでリリースが作成され、デプロイがトリガーされる可能性があります。本番環境では、書き込みに関する特定の制御されたユースケースがない限り、--read-only を渡すことを検討してください。--allow-deletes はデフォルトでオフです。エージェントが execute を介して DELETE リクエストを発行する必要がある場合にのみ有効にします。--allow-deletes と --read-only を一緒に渡すと、サーバーは起動時に警告を stderr に出力します。DELETE リクエストは読み取り専用ゲートによってブロックされたままになります。

完全な例

以下のすべての例は、環境に OCTOPUS_API_KEY が設定されていることを前提としています。--server-url フラグは明確にするために示されていますが、OCTOPUS_SERVER_URL で指定することもできます。

# Development setup with only core and project tools
npx -y @octopusdeploy/mcp-server --toolsets core,projects --server-url https://your-octopus.com

# Production setup with all tools and read-only enforcement
npx -y @octopusdeploy/mcp-server --toolsets all --read-only --server-url https://your-octopus.com

# Default invocation - all tools and writes enabled
npx -y @octopusdeploy/mcp-server --server-url https://your-octopus.com

その他のコマンドライン引数

  • --read-only - 読み取り専用モードを有効にします。すべてのキュレートされた書き込みツールを無効にし、execute を介した POST/PUT/PATCH/DELETE をブロックします。書き込みはデフォルトで有効です。このフラグはそれらをオフにします。読み取り専用モード を参照してください。
  • --allow-deletes - execute ツールを介した DELETE リクエストを許可します。--read-only が設定されている場合は無視されます (起動時に警告が表示されます)。デフォルト false。
  • --log-level <level> - 最小ログレベル (info、error)
  • --log-file <path> - ログファイルのパスまたはファイル名。指定しない場合、ログはコンソールにのみ書き込まれます
  • -q, --quiet - ファイルロギングを無効にし、エラーのみをコンソールに記録します
  • --list-tools-by-version - サポートされている Octopus サーバーのバージョン別に登録されているすべてのツールを一覧表示して終了します

🔨 ツール

URL ベースのツール

クイックスタート: Octopus URL を直接貼り付けて、手動で ID を抽出することなく問題を調査します。

  • get_deployment_from_url: デプロイ URL からデプロイの詳細を取得します (フォローアップ用の taskId を返します)
  • get_task_from_url: タスク URL からタスクの詳細とログを取得します

デプロイ調査ワークフロー:

1. get_deployment_from_url with deployment URL
   → Returns deployment context + taskResourceUri + grepTaskLogHint

2a. Fetch the structured activity tree via resources/read (or read_resource)
    octopus://spaces/{spaceName}/tasks/{taskId}/details

2b. Or call grep_task_log with the taskId to search the raw log without
    fetching the full body:
       grep_task_log({ spaceName, taskId, pattern: "error|fail", caseInsensitive: true })

タスク調査 (直接タスク URL):

get_task_from_url with task URL
→ Returns task details and logs immediately

これらのツールは、以下により手動での ID 抽出を排除します:

  • URL を自動的に解析
  • スペース ID をスペース名に解決
  • ID 形式の検証
  • 明確なエラーメッセージの提供

URL の例:

  • デプロイ: https://your-octopus.com/app#/Spaces-1/projects/my-app/deployments/Deployments-123
  • タスク: https://your-octopus.com/app#/Spaces-1/tasks/ServerTasks-456

詳細なワークフロー、例、ベストプラクティスについては、URL の操作 を参照してください。

コアツール

  • list_spaces: Octopus Deploy インスタンス内のすべてのスペースを一覧表示します
  • list_environments: 特定のスペース内のすべての環境を一覧表示します

API カタログとバックストップ

これらのツールとリソースにより、エージェントは専用のキュレートされたツールがない Octopus REST エンドポイントに到達でき、読み取り、書き込み、削除操作間のハードなサーバー側ゲーティングが行われます。

  • grep_llms_txt: Octopus APIカタログ（octopus://api/llms.txt）をgrepスタイルのセマンティクスで検索します（サポートされる最小Octopusバージョン: 2026.2.3916）。カタログ本体は大きいため（通常300KB以上）、リソース本体を直接読み取る代わりにこちらを呼び出してください。パラメータはGNU grep（pattern、caseInsensitive、invertMatch、fixedString、beforeContext、afterContext、maxCount）を反映しています。エンドポイントの発見（POST /releases）、削除エンドポイントの列挙（DELETE ）、書き込み操作のボディタイプの検索（Body: Create.*Command）に役立ちます。
  • execute: 構造化RESTのバックストップ。/api以下の任意のOctopus RESTエンドポイントに到達します。HTTPメソッドが読み取り/書き込み/削除の正式な分類子であり、LLMが設定できるisWriteフラグではありません。メソッドゲーティングはサーバー側でハードコードされています:
    • GETは常に許可されます（パス形状チェックと機密拒否リストに従います）。
    • POST/PUT/PATCHは、--read-onlyが設定されている場合はブロックされ、それ以外の場合はユーザー確認（エリシテーション）が必要です。
    • DELETEは--allow-deletesが必要であり（--read-onlyが設定されている場合はブロックされます）、さらに強力な「IRREVERSIBLE」エリシテーションメッセージが必要です。
    • 機密拒否リスト（APIキーエンドポイント、DELETE /api/spaces/{id}、DELETE /api/users/{id}）は、両方のフラグがオンでも適用されます。
    • パスは/apiであるか、/api/で始まる必要があります。絶対URL、SDK相対~/api/...パス、/api外のホスト相対パス（例: /octopus/portal/...）は事前に拒否されるため、executeはOctopus REST APIサーフェスに制限されます。
    • ツールセットごとのパス許可リストは、--toolsetsが絞り込まれた場合にのみ適用されます。 すべてのツールセットが有効な場合（デフォルト、または明示的な--toolsets all）、許可リストはバイパスされ、/api以下の任意のパスが上記のゲートに従って到達可能です。--toolsetsが絞り込まれると、許可リストがキルスイッチになります。パスは、所有するツールセットが有効な場合にのみ解決されるため、ツールセットを無効にすると（例: certificates）、executeを介したそのパスへの到達はGETでも不可能になります。

カタログデータはMCPリソースとしても公開されます:

  • octopus://api/llms.txt — すべてのOctopus RESTエンドポイント（HTTPメソッド、パス、クエリパラメータ、リクエスト/レスポンスタイプ）のMarkdownカタログ。Octopus Server 2026.2.3916以降が必要です。設定されたサーバーURLをキーとする5分間のインメモリキャッシュ。本体を直接読み取るよりもgrep_llms_txtを優先してください。
  • octopus://api/capabilities — 実行中のセッションを記述するJSON: サーバーバージョン、有効なツールセット、利用可能なツール（minimumOctopusVersion付き）、--read-only / --allow-deletesがオンかどうか。エージェントがこのセッションで到達可能なものを発見するのに役立ちます。

プロジェクト

  • list_projects: 特定のスペース内のすべてのプロジェクトを一覧表示

デプロイメント

  • deploy_release: リリースを環境にデプロイ（テナントあり/なしの両方のデプロイメントをサポート）
  • list_deployments: スペース内のデプロイメントをオプションのフィルタリング付きで一覧表示

リリース

  • create_release: プロジェクトの新しいリリースを作成
  • find_releases: スペース内のリリースを検索（IDで特定のリリースを取得、またはプロジェクトでリリースを一覧/フィルタリング）

リリースの詳細はMCPリソースとしてoctopus://spaces/{spaceName}/releases/{releaseId}でも利用可能です — resources/read（またはread_resourceバックストップツール）でフェッチして、リリースノートや選択されたパッケージを含む完全なリリース本体を取得します。

Runbook

  • find_runbooks: プロジェクト内のRunbookを検索（IDで特定のRunbookを取得、または部分名でRunbookを一覧/フィルタリング）。各サマリーには公開スナップショットID、マルチテナンシーモード、環境スコープが含まれるため、呼び出し元は実行前に有効なターゲットを選択できます。
  • run_runbook: 1つ以上の環境に対してRunbookを実行。テナント実行（テナント名またはテナントタグによる）、プロンプト変数、ガイド付き障害モード、スケジュール実行ウィンドウ、ステップまたはマシンの包含/除外をサポート。runbookSnapshotIdが省略された場合、Runbookの公開スナップショットがデフォルトで使用されます。

完全なRunbook本体（ランタイムポリシーフィールドを含む）はMCPリソースとしてoctopus://spaces/{spaceName}/runbooks/{runbookId}で利用可能です。

タスク

タスクデータは主にMCPリソースとして公開されます。resources/read（またはread_resourceバックストップツール）を以下のいずれかと共に使用します:

  • octopus://spaces/{spaceName}/tasks/{taskId} — 軽量メタデータ（状態、タイミング、完了フラグ）
  • octopus://spaces/{spaceName}/tasks/{taskId}/details — 完全なServerTaskDetails（Progress、ActivityLogsツリーなど）

ログ検索には、/logリソースではなくgrep_task_logツールを使用します:

  • grep_task_log: 完全な本体をフェッチせずにタスクのアクティビティログを検索。パラメータはGNU grep（pattern、caseInsensitive、invertMatch、fixedString、beforeContext、afterContext、maxCount）を反映しています。一致する行を1インデックスベースのlineNumber、オプションの前後コンテキスト配列、ログ全体のtotalMatchesカウントと共に返します。

意図的に/logリソースはありません: アクティビティログは数メガバイトになる可能性があり、アドレス可能なリソースがあると、ほぼ常に適切なプリミティブであるgrepの代わりに呼び出し元が本体全体をフェッチしたくなる可能性があります。

テナント

  • find_tenants: スペース内のテナントを検索（IDで特定のテナントを取得、またはフィルタでテナントを一覧/検索）
  • get_tenant_variables: タイプ別（すべて、共通、またはプロジェクト）にテナント変数を取得
  • get_missing_tenant_variables: 値が欠落しているテナント変数を取得

Kubernetes

  • get_kubernetes_live_status: プロジェクトと環境のKubernetesリソースのライブステータスを取得（サポートされる最小バージョン: 2025.3）

マシン（デプロイメントターゲット）

  • find_deployment_targets: スペース内のデプロイメントターゲットを検索（IDで特定のターゲットを取得、またはフィルタでターゲットを一覧/検索）

証明書

  • find_certificates: スペース内の証明書を検索（IDで特定の証明書を取得、またはフィルタで証明書を一覧/検索）

アカウント

  • find_accounts: スペース内のアカウントを検索（IDで特定のアカウントを取得、またはフィルタでアカウントを一覧/検索）

割り込み

  • find_interruptions: スペース内の保留中または履歴の割り込み（手動介入、承認、ガイド付き障害プロンプト）を検索し、オプションでタスク、プロジェクト、環境、関連ドキュメント、責任、保留状態でフィルタリング。スリムなサマリーを返します。完全なForm定義（コントロールタイプ、Markdown指示、ボタンオプション、送信されたForm.Values）についてはoctopus://spaces/{spaceName}/interruptions/{interruptionId}リソースを参照してください。

フィーチャートグル

  • find_feature_toggles: プロジェクト内の顧客フィーチャートグルを一覧表示。各サマリーには環境ごとの状態（isEnabled、rolloutPercentage、clientRolloutPercentage）とresourceUriが含まれるため、「Xがオンになっている場所」はリスト応答から回答可能です。
  • update_feature_toggle: 既存のトグルを調整。狭いサーフェス — 環境のオン/オフ切り替え、ロールアウト率の変更、トグルレベルの説明/デフォルト状態の更新。内部的に現在のトグルをフェッチし、メモリ内でパッチを適用し、マージされた本体をPUTするため、言及されていない環境やフィールドは保持されます。トグルにまだ設定されていない環境を参照するパッチは拒否されます。

完全なトグル本体（説明、テナント、セグメント、最小バージョン）はMCPリソースとしてoctopus://spaces/{spaceName}/projects/{projectId}/featuretoggles/{slug}で利用可能です。ロールアウトグループ本体は読み取り専用の検査のためにoctopus://spaces/{spaceName}/projects/{projectId}/rolloutgroups/{rolloutGroupId}でアドレス可能です。

対象外（Octopus UIを使用）: 新しいフィーチャートグルの作成、トグルの削除、名前変更や再タグ付け、ロールアウトグループのアタッチ/デタッチ、テナントターゲティング、セグメント、最小バージョンフィルタ、ロールアウトグループ/SDKクライアント識別子の管理。

追加ツール

  • get_deployment_process: プロジェクトまたはリリースのデプロイメントプロセスをIDで取得
  • get_variables: プロジェクトのすべてのプロジェクト変数とライブラリ変数セット変数を取得（gitRefを介したconfig-as-codeプロジェクトをサポート）
  • get_branches: バージョン管理されたプロジェクトのGitブランチを取得（サポートされる最小バージョン: 2021.2）
  • get_current_user: 現在認証されているユーザーに関する情報を取得

🔒 セキュリティに関する考慮事項

Octopus MCPサーバーには読み取り操作と書き込み操作の両方が含まれます。重要なセキュリティ上の考慮事項:

読み取り操作

  • 完全なデプロイメントログを読み取ることができ、シークレットとしてマークされていない場合、本番環境のシークレットが含まれる可能性があります
  • 機密性の高い構成データや変数へのアクセス
  • 完全に信頼できないツールやモデルに接続する際は注意が必要です

書き込み操作

デフォルトでは、以下の書き込み操作が利用可能です:

  • リリースの作成: プロジェクトの新しいリリースを作成できます
  • リリースのデプロイ: 環境（本番環境を含む）へのデプロイメントをトリガーできます
  • Runbookの実行: 環境やテナントに対してRunbookを実行できます
  • フィーチャートグルの更新: 既存のトグルの環境ごとの状態を切り替えたり、ロールアウト率を変更したりできます
  • executeバックストップを介した任意のPOST/PUT/PATCH: /api以下のパスに制限され、常時オンの機密拒否リストがあります。ツールセットごとのパス許可リストは、--toolsetsが絞り込まれた場合にのみ適用されます。すべてのツールセットが有効な場合（デフォルト）、唯一のパスゲートは/api境界と機密拒否リストです。

上記すべてを無効にするには--read-onlyを渡します。executeを介したDELETEリクエストには、追加の--allow-deletesフラグが必要です — 不可逆的な操作に対する意図的なオプトイン — であり、--read-onlyが設定されている場合はブロックされたままです。

重要なセキュリティ対策:

  1. 最小権限: ユースケースに必要な最小限の権限を持つAPIキーを使用してください
  2. 読み取り専用モードへのオプトイン: 書き込みはデフォルトで有効です。本番環境では、書き込み操作のための特定の制御されたユースケースがない限り、--read-onlyを渡してください。DELETEには常に追加の--allow-deletesオプトインが必要です。
  3. メソッドゲーティングはサーバー側でハードコードされています: executeに渡されるHTTPメソッドが正式な分類子です。エージェントは呼び出しの内容を偽ってゲートをバイパスすることはできません — POST/PUT/PATCH/DELETEリクエストは、リクエストボディの説明に関係なく、階層固有のゲーティングを受けます。
  4. ツールセットフィルタリングはキルスイッチとしても機能します: --toolsetsを絞り込むと、無効になったツールセットのキュレーションツールと、execute許可リストからのそれらのパスの両方が削除されます。（許可リストはツールセットが絞り込まれた場合にのみ参照されます。すべてのツールセットが有効な場合、executeは/api形状チェックと機密拒否リストによって制限されます。）
  5. プロンプトインジェクションリスク: エージェントを完全に自動化された方法で実行すると、プロンプトインジェクション攻撃に対して脆弱になる可能性があります

推奨事項: 本番環境では、書き込み操作のための特定の制御されたユースケースがない限り、--read-onlyを渡してください。executeを介したDELETEセマンティクスが特に必要でない限り、--allow-deletesはオフのままにしてください。

⚠️ 制限事項

データ分析

現在のAIチャットツールとMCPプロトコル自体の性質上、大量のデータを分析することは実用的ではありません。現在、ほとんどのMCPクライアントはツール呼び出しの連鎖（あるツールの出力を次のツールの入力として使用すること）をサポートしておらず、代わりに結果をトークンごとにコピーすることに依存しており、これがしばしば幻覚（ハルシネーション）につながります。分析目的でOctopusインスタンスからの履歴データを処理する場合は、APIを直接使用するか、ツール呼び出しの結果をプログラムで処理できる独自のMCPクライアントを作成することをお勧めします。

パフォーマンス

MCPサーバーは技術的には、既存のOctopus Server APIの上にある薄いレイヤーにすぎません。そのため、大量のデータを取得することが可能です（例えば、数千のデプロイメントをリクエストするなど）。このようなクエリは、インスタンスのパフォーマンスに大きな影響を与える可能性があります。モデルには、必要な最小限のデータセットのみを取得するように指示してください（ほとんどのモデルは、デフォルトでこれを非常にうまく行います）。

🤝 貢献

貢献を歓迎します！ :heart: 本プロジェクトへの参加方法については、貢献ガイドをお読みください。

Octopus MCP Serverをどのように活用される予定か、また将来のバージョンに含めてほしい機能について、ぜひお聞かせください。

フィードバックや機能リクエストは、Issuesをご利用ください。

現在Octopusをご利用のお客様は、MCPサーバーで発生した問題をサポートチームまでご報告ください。標準サポート保証の範囲内で、迅速な対応が受けられます。

🙋 FAQ

リモートMCPサーバーをリリースする予定はありますか？

Octopus ServerにMCPサーバーを直接統合する作業を進めています。これにより、より複雑なMCPツールの構築が可能になるほか、以下のようなメリットが生まれます。

  • Octopus管理者がMCPクライアントをより詳細に制御できる
  • クライアント認証にOAuthをネイティブサポート
  • MCP出力へのセキュリティスキャンツールの統合

ご興味があれば、ロードマップ項目にご登録ください。

ライセンス

本プロジェクトは、Mozilla Public License 2.0オープンソースライセンスの条項に基づいてライセンスされています。