Harness

公式

Harnessプラットフォームのデータ（パイプライン、リポジトリ、ログ、アーティファクトレジストリを含む）にアクセスし、操作します。

GitHub

104

このMCPを試すスポンサー

Harness MCPで何ができますか？

List Harness resources — AIに、harness_listを使用して組織、プロジェクト、パイプライン、その他のリソースを一覧表示するよう依頼します。
Retrieve resource details — harness_getを使用して、パイプラインやサービスなどのHarnessリソースの完全な詳細を取得します。
Create new resources — AIに、harness_createを使用してパイプライン、サービス、その他のエンティティを作成するよう指示します。
Cross-project discovery — すべてのプロジェクトにわたる失敗した実行やリソースを尋ねます。エージェントはアカウント階層を動的にナビゲートします。
Multi-user authentication — 共有デプロイメントでは、各セッションがx-harness-api-keyヘッダーを介して独自のHarness APIキーで認証できます。

ドキュメント

Harness MCP Server 2.0

AIエージェントにHarness.ioプラットフォームへの完全なアクセスを提供するMCP（Model Context Protocol）サーバーです。11の統合ツールと255のリソースタイプを通じてアクセスを実現します。

このMCPサーバーを使う理由

ほとんどのMCPサーバーは、APIエンドポイントごとに1つのツールを割り当てます。Harnessのように広範なプラットフォームの場合、240以上のツールが必要になり、ツール数が増えるほどLLMのツール選択精度は低下します。コンテキストウィンドウはスキーマで埋め尽くされ、新しいエンドポイントごとに新しいコードが必要になります。

このサーバーは異なる設計になっています：

11ツール、255リソースタイプ。 レジストリベースのディスパッチシステムがharness_list、harness_get、harness_createなどを任意のHarnessリソース（パイプライン、サービス、環境、組織、プロジェクト、フィーチャーフラグ、コストデータなど）にルーティングします。LLMは数百ではなく11のツールから選択します。
プラットフォーム全体をカバー。 CI/CD、GitOps、フィーチャーフラグ、クラウドコスト管理、セキュリティテスト、カオスエンジニアリング、データベースDevOps、内部開発者ポータル、ソフトウェアサプライチェーン、Infrastructure as Code管理、リリース管理、ガバナンス、サービスオーバーライド、ナレッジグラフなど、41のデフォルトツールセットを提供。必要に応じてオプトインのAnsibleおよび可観測性評価カバレッジも利用可能です。
マルチプロジェクトワークフローが標準装備。 エージェントが組織とプロジェクトを動的に発見します。ハードコードされた環境変数は不要です。「全プロジェクトの失敗した実行を表示」と尋ねるだけで、エージェントはアカウント階層全体をナビゲートできます。
35のプロンプトテンプレート。 一般的なワークフロー用の事前構築済みプロンプト：エンドツーエンドのアプリのビルドとデプロイ、失敗したパイプラインのデバッグ、DORAメトリクスのレビュー、脆弱性のトリアージ、クラウドコストの最適化、アクセス制御の監査、フィーチャーフラグのロールアウト計画、プルリクエストのレビュー、保留中のパイプラインの承認など。
どこでも動作。 ローカルクライアント用のStdioトランスポート（Claude Desktop、Cursor、Devin Desktop）、リモート/共有デプロイ用のHTTPトランスポート、DockerおよびKubernetes対応。
ゼロコンフィグで開始。 Harness APIキーを提供するだけです。アカウントIDはPATおよびSATトークンから自動抽出され、組織/プロジェクトのデフォルトはオプションで、ツールセットのフィルタリングにより必要なものだけを公開できます。
設計による拡張性。 新しいHarnessリソースの追加は、宣言型データファイルの追加を意味します。新しいツールの登録、スキーマ変更、プロンプトの更新は不要です。

前提条件

サーバーをインストールまたは実行する前に、Harness APIキーが必要です：

Harnessアカウントにログインします
マイプロフィール → APIキー → + 新しいAPIキー に移動します
APIキーの下に新しいトークンを作成します。これにより、<prefix>.<accountId>.<tokenId>.<secret>形式のPATまたはSATが生成されます
トークンを安全な場所に保存します。次のステップで必要になります

詳細な手順については、Harness APIクイックスタートを参照してください。

クイックスタート

オプション0：ホステッドHarness MCP

HarnessアカウントでホステッドMCPサービスが有効になっている場合、リモートMCPサーバーをサポートするクライアントは、サーバーをローカルで実行する代わりに管理エンドポイントに直接接続できます。

重要： ホステッドMCPサービスはHarnessプラットフォームOAuthを使用し、HARNESS_API_KEYは使用しません。また、エンドポイントを使用する前に、Harnessサポートによるアカウントごとの有効化/設定が必要です。

設定例についてはホステッドHarness MCPを参照してください。

オプション1：npx（推奨）

インストール不要です。実行するだけです：

HARNESS_API_KEY=pat.xxx.xxx.xxx npx harness-mcp-v2@latest

または、AIクライアントでAPIキーを設定します（下記のクライアント設定を参照）。

# Stdio transport (default — for Claude Desktop, Cursor, Devin Desktop, etc.)
HARNESS_API_KEY=pat.xxx npx harness-mcp-v2

# HTTP transport (for remote/shared deployments)
HARNESS_API_KEY=pat.xxx npx harness-mcp-v2 http --port 8080

注：アカウントIDはPATおよびSATトークン（pat.<accountId>...またはsat.<accountId>...）から自動抽出されるため、HARNESS_ACCOUNT_IDはアカウントセグメントが埋め込まれていないAPIキーにのみ必要です。

オプション2：グローバルインストール

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

オプション3：ソースからビルド

開発またはカスタマイズ用：

git clone https://github.com/harness/mcp-server.git
cd mcp-server
pnpm install
pnpm build

# Run
pnpm start              # Stdio transport
pnpm start:http         # HTTP transport
pnpm inspect            # Test with MCP Inspector

Anthropic MCPディレクトリバンドル

MCPBバンドルマニフェストは[mcp-directory/](mcp-directory/)にあり、512×512のバンドルアイコンはリポジトリルートの[icon.png](icon.png)で追跡されています。パッケージ化されたアーカイブには、ルートレベルのmanifest.json、icon.png、server/、package.json、npm-shrinkwrap.json、および本番用のnode_modules/が含まれています。

アーカイブを小さく保つために、ステージングディレクトリからMCPBパッケージをビルドします：

pnpm prepare:mcpb

ステージングディレクトリはdist/mcpb/に書き込まれ、本番依存関係はnpmのフラットレイアウトを使用してnpm-shrinkwrap.jsonからインストールされます。固定された公式MCPB CLIがそれを検証し、dist/harness-mcp-server-<version>.mcpbを作成します。

v*.*.*に一致するバージョンタグは、そのバンドルを対応するGitHubリリースに自動的に公開します。npmを再公開せずに既存のリリースをバックフィルするには、Releaseワークフローをrelease_tag入力（例：v3.2.20）を指定して手動で実行します。ワークフローは、その正確なタグをチェックアウトしてビルドしてから、バージョン付きMCPBアセットのみを置き換えます。

CLI使用法

harness-mcp-v2 [stdio|http] [--port <number>]

Options:
  --port <number>  Port for HTTP transport (default: 3000, or PORT env var)
  --help           Show help message and exit
  --version        Print version and exit

指定がない場合、トランスポートはデフォルトでstdioになります。リモート/共有デプロイにはhttpを使用します。

HTTPトランスポート

HTTPモードで実行すると、サーバーは以下を公開します：

エンドポイント	メソッド	説明
`/mcp`	`POST`	MCP JSON-RPCエンドポイント（initialize + セッションリクエスト）
`/mcp`	`GET`	サーバー開始メッセージ用のSSEストリーム（進捗、引き出し）
`/mcp`	`DELETE`	アクティブなMCPセッションを終了
`/mcp`	`OPTIONS`	CORSプリフライト
`/health`	`GET`	ヘルスチェック — `{ "status": "ok", "sessions": <count> }`を返します
`/.well-known/oauth-protected-resource`	`GET`	`HARNESS_MCP_MODE=oauth`時のRFC 9728メタデータ
`/.well-known/oauth-protected-resource/mcp`	`GET`	デフォルトの`/mcp`リソース用のパス認識RFC 9728メタデータ

HTTPトランスポートはセッションベースモードで実行されます。initializeで新しいMCPセッションが作成され、サーバーはmcp-session-idヘッダーを返し、そのセッションへの後続のリクエストには同じヘッダーを含める必要があります。

HTTPモードでの運用上の制約：

共有またはリモートから到達可能なシングルユーザーおよびマルチユーザーデプロイにはHARNESS_MCP_AUTH_TOKENを設定します。設定すると、/mcpへのすべてのPOST、GET、およびDELETEリクエストにAuthorization: Bearer <token>を含める必要があります。
OAuthモードはHARNESS_MCP_AUTH_TOKENの代わりにHarnessIDアクセストークンを受け入れ、未認証のオプトアウトなしで非ループバックアドレスにバインドできます。
非ループバックのシングルユーザーおよびマルチユーザーバインドには、デフォルトでHARNESS_MCP_AUTH_TOKENが必要です。それでも非ループバックインターフェースで未認証で実行するには、HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=trueを明示的に設定します。
mcp-session-idなしのPOST /mcpはinitializeリクエストである必要があります。
既存セッションのPOST /mcp、GET /mcp、およびDELETE /mcpにはmcp-session-idヘッダーが必要です。
GET /mcpはSSE通知（進捗更新と引き出しプロンプト）に使用されます。
アイドルセッションは、リクエストまたはSSEストリームがアクティブでなくなってからMCP_SESSION_TTL_MSミリ秒後に回収されます（デフォルト1800000、つまり30分）。
GET /healthは唯一の非MCPエンドポイントです。
リクエストボディサイズはHARNESS_MAX_BODY_SIZE_MBによって制限されます（デフォルト10MB）。
initializeリクエストにx-harness-pipeline-version: 0または1を設定して、そのHTTPセッションのV0またはV1パイプラインリソースを選択します。
initializeリクエストにx-harness-auto-approve-risk: none|low_write|medium_write|high_write|allを設定して、より厳格なセッションごとの自動承認しきい値を選択します。サーバーはこの値をデプロイメントレベルのHARNESS_AUTO_APPROVE_RISKに上限設定するため、セッションは設定された承認上限を減らすことはできますが、拡大することはできません。

HarnessID OAuthモード

HARNESS_MCP_MODE=oauthを設定して、リモートMCPクライアントがHarnessIDを発見し、PKCEを使用したOAuth 2.1 Authorization Codeを完了できるようにします。OAuthモードはHTTPトランスポートでのみ利用可能です。本番のHarnessID、MCPリソース、およびAPIルーティングのデフォルトが組み込まれています：

HARNESS_MCP_MODE=oauth

これはデフォルトで発行者https://id.harness.io/idp/realms/HarnessIDP、リソースhttps://mcp.harness.io/mcp、OAuthクライアントmcp-client、およびHarness APIベースhttps://mcp.harness.io/cliになります。QA、ローカル開発、または別のHarness環境の場合にのみ上書きします。

このモードではHARNESS_API_KEYを設定してはなりません。HARNESS_MCP_OAUTH_JWKS_URIはデフォルトで<issuer>/protocol/openid-connect/certsになり、アカウントはトークンから取得されるためHARNESS_ACCOUNT_IDは不要です。

サーバーはRFC 9728保護リソースメタデータを公開し、クライアントが認証されていない場合にこのチャレンジを返します：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.harness.io/.well-known/oauth-protected-resource/mcp"

設定されたJWKSエンドポイントを使用して、HarnessIDアクセストークンのRS256署名、iss、有効期限、およびsubを検証し、トークンがazpクレームを通じてHARNESS_MCP_OAUTH_CLIENT_IDに発行されたことを確認します。HARNESS_MCP_OAUTH_RESOURCEは、発見とチャレンジに使用されるRFC 9728保護リソース識別子です。現在のHarnessIDアクセストークンはMCP URLではなくaud: accountを使用するため、リソースはaudと比較されません。

アカウントIDはトークンのHARNESS_MCP_OAUTH_ACCOUNT_CLAIMクレーム（デフォルトでaccount_id）から取得され、HarnessIDのorganizationスコープがそれを設定します。各セッションは呼び出し元のアクセストークンを保存し、Authorization: BearerとしてHarness APIに転送するため、Harness RBACと監査記録は共有PATではなくログインしたユーザーを反映します。セッションは作成時に使用されたsubとアカウントにバインドされます。後続のリクエストは更新されたトークンを運ぶことができますが、別のユーザーまたはアカウントのものは拒否されます。

クライアントは通常、MCPリソースURLのみが必要です：

{
  "mcpServers": {
    "harness": {
      "url": "https://mcp.harness.io/mcp"
    }
  }
}

クライアントは保護リソースメタデータを読み取り、HARNESS_MCP_OAUTH_ISSUERを発見し、その認証サーバーのRFC 8414メタデータを使用します。クライアントが動的クライアント登録をサポートしていない場合は、事前登録されたmcp-clientクライアントIDを使用します。

QA Keycloakチェックリストと検証コマンドについては、セルフホストMCPサーバー用のHarnessID OAuthを参照してください。

マルチユーザーモード

各クライアントが異なるHarnessユーザーとして認証する共有HTTPデプロイにはHARNESS_MCP_MODE=multi-userを設定します。このモードでは：

サーバー設定でHARNESS_API_KEYを設定してはなりません。サーバーはHarness資格情報を保持しません。
各セッションはinitializeリクエストでx-harness-api-keyを提供する必要があります。x-harness-account-idはAPIキーにアカウントセグメントが埋め込まれていない場合にのみ必要です。
セッションはx-harness-orgおよびx-harness-projectヘッダーを提供して、そのセッションのデフォルトスコープを設定することもできます。
Harness APIキーはそのセッションのすべてのHarness API呼び出しに流れるため、Harnessの監査証跡は実際のユーザーを反映します。
HARNESS_MCP_AUTH_TOKENは独立しており、追加のトランスポート層ゲートとして引き続き使用できます。

# Health check
curl http://localhost:3000/health

# MCP initialize request (capture mcp-session-id response header)
# In multi-user mode, x-harness-api-key is required on initialize.
# x-harness-account-id is needed only for API keys without an embedded account segment.
curl -i -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $HARNESS_MCP_AUTH_TOKEN" \
  -H "x-harness-api-key: $HARNESS_API_KEY" \
  -H "x-harness-account-id: $HARNESS_ACCOUNT_ID" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'

# Subsequent MCP request (use returned session ID)
curl -X POST http://localhost:3000/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer $HARNESS_MCP_AUTH_TOKEN" \
  -H "mcp-session-id: <session-id>" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

# Terminate session
curl -X DELETE http://localhost:3000/mcp \
  -H "Authorization: Bearer $HARNESS_MCP_AUTH_TOKEN" \
  -H "mcp-session-id: <session-id>"

HARNESS_MCP_ALLOWED_HOSTSはDNSリバインディング保護のためのHostヘッダー検証を制御し、CORSはブラウザオリジンを制限します。どちらも認証ではありません。アクセス制御にはHARNESS_MCP_AUTH_TOKENまたは認証されたゲートウェイ/リバースプロキシを使用します。

クライアント設定

注： HARNESS_ORGとHARNESS_PROJECTはオプションです。これらは、ツール呼び出しごとに指定されていない場合に使用される組織IDとプロジェクトIDを設定します。エージェントはharness_list(resource_type="organization")とharness_list(resource_type="project")を使用して組織とプロジェクトを動的に発見できます。非推奨の名前HARNESS_DEFAULT_ORG_IDとHARNESS_DEFAULT_PROJECT_IDは後方互換性のために引き続き受け入れられます。

ホステッドHarness MCP

Harnessは、マネージドサービスが有効になっているアカウント向けにホステッドMCPエンドポイントもサポートしています。これは、npx harness-mcp-v2を実行したりHTTPトランスポートをセルフホストしたりする代わりに、共有リモートMCPエンドポイントが必要な場合に便利です。

重要: ホステッドMCP認証はHarness Platform OAuthを使用します。クライアント設定でHARNESS_API_KEYは使用しません。ホステッドMCPの利用可否はHarnessアカウントごとに設定されるため、使用前にHarnessサポートと連携して設定を有効化・構成する必要があります。

ホステッドエンドポイントhttps://mcp.harness.io/mcpはマネージドサービスです。Claude、Cursor、またはCoworkでのクライアント側MCP設定では、ルーティング先のHarness環境を上書きできません。Harness0または別のプライベートHarness SaaS環境の場合は、Harnessサポートにその環境でのホステッドMCPの有効化・構成を依頼するか、ローカル/セルフホストサーバーを実行してHARNESS_BASE_URLを対象のHarnessホストに設定してください。

ホステッドMCPの例:

{
  "mcpServers": {
    "harness-prod1-mcp": {
      "url": "https://mcp.harness.io/mcp",
      "auth": {
        "CLIENT_ID": "mcp-client"
      }
    }
  }
}

ホステッドとローカルの両方のエントリを含む例:

{
  "mcpServers": {
    "harness-hosted": {
      "url": "https://mcp.harness.io/mcp",
      "auth": {
        "CLIENT_ID": "mcp-client"
      }
    },
    "harness-local": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2@latest"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

npx ENOENTまたはnode: No such file or directoryのトラブルシューティング

これはクライアントのプロセス起動失敗であり、Harness認証の失敗ではありません。MCPサーバーがまだ起動していないため、HARNESS_API_KEYを変更してもspawn npx ENOENTには影響しません。

GUIアプリ（Cursor、Claude Desktop、Devin Desktop、VS Code）はシェルのPATHを常に継承するとは限らないため、設定の再読み込み後にnpxまたはnodeを見つけられない場合があります。これを修正するには、絶対パスを使用し、envブロックでPATHを明示的に設定してください：
{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}
ターミナルでwhich npxとwhich nodeを使用してパスを確認し、nodeを含むディレクトリが上記のPATHの値に含まれていることを確認してください。一般的な場所は次のとおりです：

Homebrew（macOS）： /opt/homebrew/bin/npx

nvm： ~/.nvm/versions/node/v20.x.x/bin/npx（正確なパスを確認するにはnvm which currentを実行）

システムNode： /usr/local/bin/npx

Claude Desktop（`claude_desktop_config.json`）

npx（ゼロインストール）

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2@latest"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

node（ローカルインストール）

npm install -g harness-mcp-v2

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/harness-mcp-v2",
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

Claude Code（`claude mcp add`経由）

npx（ゼロインストール）

claude mcp add harness -- npx harness-mcp-v2

node（ローカルインストール）

npm install -g harness-mcp-v2
claude mcp add harness -- harness-mcp-v2

次に、環境または.envファイルでHARNESS_API_KEYを設定します。

Cursor（`.cursor/mcp.json`）

npx（ゼロインストール、ローカルCursor設定に推奨）

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2@latest"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

ターミナルでwhich npxを実行し、その完全なパスをcommandに使用します。which nodeのディレクトリをPATHの先頭に含めてください。

node（ローカルインストール）

npm install -g harness-mcp-v2

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/harness-mcp-v2",
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

npm install -g harness-mcp-v2の後にwhich harness-mcp-v2を実行し、その完全なパスをcommandに使用します。which nodeのディレクトリをPATHの先頭に含めてください。

Devin Desktop（`~/.windsurf/mcp.json`）

npx（ゼロインストール）

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2@latest"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

node（ローカルインストール）

npm install -g harness-mcp-v2

{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/harness-mcp-v2",
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/directory/containing/node:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

ソースからローカルビルドを使用していますか？

コマンドをビルド済みのindex.jsへのパスに置き換えてください：

{
  "command": "node",
  "args": ["/absolute/path/to/harness-mcp-v2/build/index.js", "stdio"]
}

MCPゲートウェイ

Harness MCPサーバーはMCPゲートウェイと完全に互換性があります。MCPゲートウェイは、複数のMCPサーバーにわたって集中認証、ガバナンス、ツールルーティング、および可観測性を提供するリバースプロキシです。サーバーはstdioおよびHTTPトランスポートの両方で標準のMCPプロトコルを実装しているため、コード変更なしでMCP準拠の任意のゲートウェイの背後で動作します。

ゲートウェイを使用する理由：

集中化された資格情報管理 — エージェント設定にAPIキーが不要
チーム全体のすべてのツール呼び出しに対するガバナンスと監査ログ
N個のMCPサーバーへのN接続ではなく、エージェント用の単一エンドポイント
アクセス制御 — どのチームがどのツールを使用できるかを制限

Docker MCPゲートウェイ

Docker MCPゲートウェイ設定にサーバーを登録します：

{
  "mcpServers": {
    "harness": {
      "command": "npx",
      "args": ["harness-mcp-v2"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx"
      }
    }
  }
}

Portkey

エンタープライズガバナンス、コスト追跡、およびマルチLLMルーティングのために、Harness MCPサーバーをPortkey MCP Gatewayに追加します：

{
  "mcpServers": {
    "harness": {
      "command": "npx",
      "args": ["harness-mcp-v2"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx"
      }
    }
  }
}

LiteLLM

LiteLLMプロキシ設定に追加します：

mcp_servers:
  - name: harness
    command: npx
    args:
      - harness-mcp-v2
    env:
      HARNESS_API_KEY: "pat.xxx.xxx.xxx"

Envoy AI Gateway

サーバーはHTTPトランスポートを介してEnvoy AI GatewayのMCPサポートで動作します：

# Start the server in HTTP mode
HARNESS_API_KEY=pat.xxx.xxx.xxx npx harness-mcp-v2 http --port 8080

次に、EnvoyがアップストリームMCPバックエンドとしてhttp://localhost:8080/mcpにルーティングするように設定します。

Kong

KongのAI MCPプロキシプラグインを使用して、既存のKongゲートウェイインフラストラクチャを通じてHarness MCPサーバーを公開します。

その他のゲートウェイ

MCP仕様をサポートする任意のゲートウェイ（Microsoft MCP Gateway、IBM ContextForge、Cloudflare Workersなど）がこのサーバーをプロキシできます。stdioベースのゲートウェイの場合は、デフォルトのトランスポートを使用します。HTTPベースのゲートウェイの場合は、httpトランスポートでサーバーを起動し、ゲートウェイを/mcpエンドポイントに向けます。

Docker

サーバーをDockerコンテナとしてビルドして実行します：

# Build the image
pnpm docker:build

# Run with your .env file
pnpm docker:run

# Or run directly with env vars
docker run --rm -p 3000:3000 \
  -e HARNESS_API_KEY=pat.xxx.xxx.xxx \
  -e HARNESS_ACCOUNT_ID=your-account-id \
  harness-mcp-server

コンテナはデフォルトでポート3000のHTTPモードで実行され、組み込みのヘルスチェックが含まれます。

Kubernetes

提供されたマニフェストを使用してKubernetesクラスターにデプロイします：

# 1. Edit the Secret with your real credentials
#    k8s/secret.yaml — replace HARNESS_API_KEY and HARNESS_ACCOUNT_ID

# 2. Apply all manifests
kubectl apply -f k8s/

# 3. Verify the deployment
kubectl -n harness-mcp get pods

# 4. Port-forward for local testing
kubectl -n harness-mcp port-forward svc/harness-mcp-server 3000:80
curl http://localhost:3000/health

デプロイメントは、準備/生存プローブ、リソース制限、および非ルートセキュリティコンテキストを持つ2つのレプリカを実行します。Serviceは内部でポート80を公開します（コンテナポート3000をターゲットにします）。

設定

サーバーは、プロジェクトルートに.envファイルが存在する場合、そこから環境変数を自動的に読み込みます。.env.exampleを.envにコピーして、値を入力してください。環境変数は、シェルまたはMCPクライアント設定を介して設定することもできます。

変数	必須	デフォルト	説明
`HARNESS_MCP_MODE`	いいえ	`single-user`	デプロイモード: `single-user` (共有APIキー)、`multi-user` (セッションごとのAPIキーを使用するHTTP)、または `oauth` (HarnessIDアクセストークン検証を使用するHTTP)
`HARNESS_API_KEY`	はい*	--	Harnessパーソナルアクセストークンまたはサービスアカウントトークン。`single-user` モードで必須です。`multi-user` または `oauth` モードでは設定してはなりません。各セッションが独自の認証情報を持ち込みます
`HARNESS_ACCOUNT_ID`	いいえ	(PAT/SATから)	Harnessアカウント識別子。シングルユーザーモードではPAT/SATトークンから自動抽出されます。マルチユーザーセッションでは、APIキーに埋め込まれていない場合、`x-harness-account-id` を介して独自のものを提供できます
`HARNESS_BASE_URL`	いいえ	`https://app.harness.io` (OAuthモードでは `https://mcp.harness.io/cli`)	Harness API/UIベースURL。OAuthモードはデフォルトでホスト型MCP `/cli` プロキシを経由します。他のモードはHarness SaaS APIを直接使用します
`HARNESS_MCP_OAUTH_ISSUER`	いいえ	`https://id.harness.io/idp/realms/HarnessIDP`	アクセストークンの `iss` クレームと完全一致で照合されるHarnessID発行者
`HARNESS_MCP_OAUTH_RESOURCE`	いいえ	`https://mcp.harness.io/mcp`	RFC 9728リソース識別子として公開されるパブリック正規MCP URL
`HARNESS_MCP_OAUTH_JWKS_URI`	いいえ	`<issuer>/protocol/openid-connect/certs`	RS256アクセストークン署名の検証に使用されるHarnessID JWKSエンドポイント
`HARNESS_MCP_OAUTH_CLIENT_ID`	いいえ	`mcp-client`	アクセストークンが発行される必要があるHarnessIDクライアント。トークンの `azp` クレームと照合されます
`HARNESS_MCP_OAUTH_ACCOUNT_CLAIM`	いいえ	`account_id`	HarnessアカウントIDを運ぶアクセストークンクレーム。HarnessID `organization` スコープによって設定されます
`HARNESS_MCP_OAUTH_SCOPES`	いいえ	`openid profile email organization`	RFC 9728保護リソースメタデータでアドバタイズされるスペース区切りのスコープ
`HARNESS_FME_API_KEY`	いいえ	--	レガシー (`workspace_id`) モードのみで `fme_` リソースに使用されるオプションのシングルユーザー/セルフホストFME/Split管理者認証情報。レガシーFMEはOAuthモードでは利用できないため、HarnessIDトークンが `api.split.io` に送信されることはありません。代わりにHarnessネイティブの `org_id`+`project_id` スコープを使用してください。`multi-user` または `oauth` モードでは設定してはなりません
`HARNESS_FME_BASE_URL`	いいえ	`https://api.split.io`	レガシー (`workspace_id`) モードのみで `fme_` リソースによって使用されるSplit/FME管理者APIベースURL。HTTP URLはローカル開発に `HARNESS_ALLOW_HTTP=true` が必要です。Harnessネイティブ (`org_id`+`project_id`) モードはこれを無視し、代わりに標準の `HARNESS_API_KEY`/`HARNESS_BASE_URL` を使用します
`HARNESS_ORG`	いいえ	--	組織ID。ツール呼び出しごとに `org_id` が指定されていない場合に使用されます。省略された場合、`org_id` を明示的に指定する必要があります。エージェントは `harness_list(resource_type="organization")` を介して組織を動的に発見することもできます
`HARNESS_PROJECT`	いいえ	--	プロジェクトID。ツール呼び出しごとに `project_id` が指定されていない場合に使用されます。エージェントは `harness_list(resource_type="project")` を介してプロジェクトを動的に発見することもできます
`HARNESS_API_TIMEOUT_MS`	いいえ	`30000`	HTTPリクエストタイムアウト（ミリ秒）
`HARNESS_MAX_RETRIES`	いいえ	`3`	一時的な障害（429、5xx）に対する再試行回数
`HARNESS_MAX_BODY_SIZE_MB`	いいえ	`10`	`http` トランスポートの最大HTTPリクエストボディサイズ（MB）
`HARNESS_RATE_LIMIT_RPS`	いいえ	`10`	Harness APIへのクライアント側リクエストスロットル（1秒あたりのリクエスト数）
`LOG_LEVEL`	いいえ	`info`	ログの詳細度: `debug`、`info`、`warn`、`error`
`HARNESS_TOOLSETS`	いいえ	(デフォルト)	カンマ区切りのツールセットリスト。空の場合はデフォルトのツールセットが読み込まれます。オプトインツールセットを明示的に含めるための `+name` と、デフォルトを削除するための `-name` をサポートします（ツールセットフィルタリングを参照）
`HARNESS_READ_ONLY`	いいえ	`false`	すべての変更操作（作成、更新、削除、実行）をブロックします。リストと取得のみが許可されます。共有/デモ環境に役立ちます
`HARNESS_AUTO_APPROVE_RISK`	いいえ	`none`	自律ワークフローのリスクベースの自動承認しきい値。このリスク以下の操作は確認なしで進行します。値: `none`、`low_write`、`medium_write`、`high_write`、`all`。引き出しを参照
`HARNESS_SKIP_ELICITATION`	いいえ	`false`	非推奨 — 代わりに `HARNESS_AUTO_APPROVE_RISK=all` を使用してください。後方互換性のために保持されています
`HARNESS_ALLOW_HTTP`	いいえ	`false`	非HTTPS `HARNESS_BASE_URL` を許可します。デフォルトでは、サーバーはセキュリティのためにHTTPSを強制します。TLSなしのHarnessインスタンスに対するローカル開発の場合のみ `true` に設定してください
`HARNESS_PIPELINE_VERSION`	いいえ	`0`	(アルファ) パイプラインYAMLバージョン。`0` は `pipeline` リソースタイプを読み込み、`pipeline_v1` を除外します。`1` は `pipeline_v1` を読み込み、`pipeline` を除外します。HTTPセッションは初期化時に `x-harness-pipeline-version: 0` または `1` でこれを上書きできます
`HARNESS_MCP_ALLOWED_HOSTS`	いいえ	--	HTTPトランスポートのHostヘッダー検証で許可されるカンマ区切りのホスト名。localhostバインドでは `mcp.harness.io` がデフォルトで許可されます。プロキシ/カスタムドメインはここに追加してください
`HARNESS_MCP_AUTH_TOKEN`	いいえ	--	設定されている場合、`/mcp` HTTPルートで必要な静的Bearerトークン。非ループバックのシングルユーザーおよびマルチユーザーバインドではデフォルトで必須です。`oauth` モードでは未設定にする必要があります
`HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP`	いいえ	`false`	非ループバックバインドで認証なしのHTTPトランスポートを明示的に許可します。別の認証された制御の背後でのみ使用してください
`HARNESS_MCP_TRUST_PROXY`	いいえ	`0`	クライアントIP解決のために信頼するリバースプロキシ/ロードバランサーホップ数（Express `trust proxy`）。サーバーの前のプロキシ数に設定して、per-IPレート制限がプロキシソケットピアではなく実際のクライアントにキー付けされるようにします
`HARNESS_MCP_LOG_FILE`	いいえ	`~/.claude/harness-mcp.log`	stderrが利用できなくなった可能性がある場合のstdio切断/クラッシュ診断に使用されるファイル
`HARNESS_LOG_UNSAFE_BODIES`	いいえ	`false`	ログに生のリクエスト/レスポンスボディを含めます。ボディにはシークレットが含まれる可能性があるため、デフォルトではオフです。ローカルデバッグの場合のみ有効にしてください
`HARNESS_AUDIT_FILE`	いいえ	--	監査イベントを改行区切りのJSONファイルに追加して、耐久性のあるローカル収集を行います
`HARNESS_AUDIT_WEBHOOK_URL`	いいえ	--	バッチ処理された監査イベントを受信するHTTPSエンドポイント。HTTP URLはローカル開発に `HARNESS_ALLOW_HTTP=true` が必要です
`HARNESS_AUDIT_WEBHOOK_TOKEN`	いいえ	--	監査ウェブフックに送信されるオプションのBearerトークン
`HARNESS_AUDIT_WEBHOOK_BATCH_SIZE`	いいえ	`10`	ウェブフックフラッシュの前にバッチ処理する監査イベントの数
`HARNESS_AUDIT_WEBHOOK_FLUSH_MS`	いいえ	`5000`	Webhookフラッシュ前に監査イベントを保持する最大時間
`OTEL_EXPORTER_OTLP_ENDPOINT`	いいえ	--	オプションのOpenTelemetryパッケージがインストールされている場合、OpenTelemetry監査スパンを有効にします
`HARNESS_SEARCH_PROVIDER`	いいえ	`local`	セマンティック検索バックエンド: `local` (プロセス内ONNX埋め込み、デフォルト)、`remote` (HTTP経由の外部検索サービス、マルチユーザーモードで必須)、または `none` (セマンティック検索を無効化し、キーワードのスキャッターギャザーのみにフォールバック)。エアギャップ環境や起動時のモデル読み込みが望ましくない場合は `none` を使用します
`HARNESS_SEARCH_SERVICE_URL`	いいえ	--	`HARNESS_SEARCH_PROVIDER=remote` 使用時のリモート検索サービスのベースURL (例: `http://search-svc:8080`)。`remote` プロバイダーを使用する場合に必須です
`HARNESS_SEARCH_SERVICE_HEADERS`	いいえ	--	リモート検索サービスへのすべてのリクエストで送信されるヘッダーのJSONオブジェクト。`{"Authorization":"Bearer tok"}`、`{"x-api-key":"key"}`、または複数の内部サービス間ヘッダーなど、任意の認証スキームをサポートします
`HARNESS_HF_CACHE_DIR`	いいえ	`/tmp/hf-cache`	`local` 検索プロバイダーが使用する `@huggingface/transformers` モデルキャッシュのディレクトリ。Dockerイメージはランタイムダウンロードを避けるため、モデルを `/app/.cache/hf` に事前に組み込みます。本番デプロイメントでは永続ボリュームパスに設定してください
`HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY`	いいえ	`3`	失敗したステップのログを取得する際に `harness_diagnose` が発行する最大同時ログブロブダウンロード数。診断レイテンシがログ取得のウォールクロック時間によって支配され、ポッドにメモリの余裕がある場合のみ増やしてください

セマンティック検索

harness_search はセマンティックルーティングを使用して、Harness へのファンアウト前にスキャッターギャザー API 呼び出しを絞り込みます。利用可能な検索プロバイダーは3つあります：

プロバイダー	使用タイミング
`local`（デフォルト）	シングルユーザーの stdio モード。`all-MiniLM-L6-v2` を `@huggingface/transformers` 経由でインプロセス実行します。初回使用時に約23 MBのモデルをダウンロードします。以降の起動ではキャッシュを使用します。
`remote`	マルチユーザーの HTTP モード（Harness ホスト）。埋め込みと取得を外部検索サービスに委任します。テナント分離は `tenant_id` によって強制されます — 静的ナレッジ/ドキュメントは `global` を使用し、アカウントごとのエンティティデータはアカウント ID を使用します。
`none`	セマンティック検索を完全に無効化します。すべてのリソースタイプにわたるキーワードのスキャッターギャザーにフォールバックします。

リモートプロバイダーの設定：

HARNESS_SEARCH_PROVIDER=remote
HARNESS_SEARCH_SERVICE_URL=http://search-svc:8080

# Auth — any scheme via HARNESS_SEARCH_SERVICE_HEADERS (JSON object):
HARNESS_SEARCH_SERVICE_HEADERS='{"Authorization":"Bearer <token>"}'   # standard bearer
HARNESS_SEARCH_SERVICE_HEADERS='{"x-api-key":"<key>"}'               # API key header
HARNESS_SEARCH_SERVICE_HEADERS='{"x-harness-token":"<svc-token>"}'   # internal service-to-service
# Multiple headers (e.g. service mesh + tenant routing):
HARNESS_SEARCH_SERVICE_HEADERS='{"x-harness-token":"<tok>","x-tenant":"<id>"}'
# No auth (service mesh / mTLS handles it):
# omit HARNESS_SEARCH_SERVICE_HEADERS entirely

付属のスタブサービスを使用したリモートプロバイダーのローカルテスト（外部依存関係なし）：

# 1. Create a venv and install FastAPI
python3 -m venv .venv-stub
.venv-stub/bin/pip install fastapi uvicorn

# 2. Start the stub (in-memory, cosine similarity, corpus + tenant filtering)
.venv-stub/bin/uvicorn stub-search-service:app --port 8082

# 3. Build the MCP server
pnpm build

# 4. Run the integration smoke test
node test-remote-provider.mjs
# Expected output:
#   available: true
#   indexed 2 docs
#   entity search results: pipeline:ts-test score=... corpus=entities
#   knowledge search results: schema:trigger score=...
#   all-corpus search results: (merged, sorted by score)
#   isolation check (other-acct, should be empty): PASS

# 5. Tear down
kill $(lsof -ti :8082)

スタブ（stub-search-service.py）は、本番検索サービスと同じ /v1/health、/v1/ingest、/v1/search コントラクトを実装しています。単純な bag-of-chars 埋め込みを使用するため、モデルのダウンロードは不要です — 結果は意味的に妥当ですが、本番品質ではありません。

HTTPS の強制

HARNESS_BASE_URL はデフォルトで HTTPS を使用する必要があります。非 HTTPS の URL（例：http://localhost:8080）を設定した場合、サーバーは以下のエラーで起動を拒否します：

HARNESS_BASE_URL must use HTTPS (got "http://..."). If you need HTTP for local development, set HARNESS_ALLOW_HTTP=true.

監査ログ

レジストリによってディスパッチされるすべての Harness API 操作（list、get、create、update、delete、execute）は、監査シンクが設定されている場合に構造化監査イベントを出力します。変更イベントには、確認コンテキストが存在する場合に elicitation または自動承認で使用される確認パスが含まれます。読み取りイベントは現在、確認メタデータを省略します。レジストリをバイパスするローカルメタデータおよびスキーマ検出ツール（harness_describe や harness_schema など）は、この監査ストリームの対象外です。stderr シンクはデフォルトで登録されますが、通常のロガーを経由し、LOG_LEVEL に従います。永続的な監査収集にはファイルまたは Webhook シンクを設定してください：

HARNESS_AUDIT_FILE は、ローカル収集用に改行区切りの JSON イベントを追記します。
HARNESS_AUDIT_WEBHOOK_URL は { "events": [...] } バッチを HTTPS Webhook に投稿します。オプションで HARNESS_AUDIT_WEBHOOK_TOKEN を使用できます。失敗したバッチは制限付き容量で再エンキューされ、最終的にツールの実行をブロックせずに警告とともに破棄されます。
OTEL_EXPORTER_OTLP_ENDPOINT は、オプションの OpenTelemetry ピア依存関係がインストールされている場合に監査スパンを有効にします。このシンクは、既存のトレーサープロバイダーが登録されている場合はそれを再利用し、それ以外の場合はスタンドアロンの OTLP エクスポーターをブートストラップします。

各イベントには、ツール名、リソースタイプ、操作、識別子、タイムスタンプ、リスク、結果、HTTP メソッド/パス、期間、および該当する場合は確認方法が含まれます。監査シンクはベストエフォートのテレメトリです。配信の問題はログに記録され、基盤となる Harness API 操作を再生または変更することはありません。OTel のセットアップ詳細とスパン属性については、specs/005-otel-audit-sink.md を参照してください。

ツールリファレンス

サーバーは11個の MCP ツールを公開しています。ほとんどの API ツールは、オプションのオーバーライドとして org_id と project_id を受け入れます — 省略された場合、HARNESS_ORG と HARNESS_PROJECT にフォールバックします。harness_describe はローカルメタデータのみで、組織/プロジェクトのスコープは使用しません。

URL サポート： ほとんどの API 向けツールは url パラメータを受け入れます — Harness UI の URL を貼り付けると、サーバーが組織、プロジェクト、リソースタイプ、リソース ID、パイプライン ID、実行 ID を自動抽出します。harness_describe は url を受け入れません。

スコープサポート： アカウント/組織/プロジェクトのバリアントを持つリソースタイプは、harness_describe で supportedScopes を公開します。特定のレベルが必要な場合は resource_scope を渡します：

resource_scope: "account" は accountIdentifier のみを送信します。
resource_scope: "org" は accountIdentifier と orgIdentifier を送信します。
resource_scope: "project" はアカウント、組織、プロジェクトの識別子を送信します。

現在のマルチスコープリソースには、connector、service、environment、infrastructure、secret、file_store、template、policy、policy_set が含まれます。resource_scope が省略された場合、レジストリはリソースのデフォルトスコープと設定済みデフォルトを使用します。ただし、オプションスコープとしてマークされたリソースは、明示的に渡されない限り組織/プロジェクトを省略できます。Harness URL は、パスにアカウントレベルまたはプロジェクトレベルのコンテキストが含まれている場合、スコープを自動的に設定することもできます。

構造化出力： すべてのツールは MCP outputSchema を宣言します。harness_list は、リスト形式の Harness レスポンスをオブジェクト形式の構造化コンテンツに正規化し、厳格なクライアントが検証できるようにします：トップレベルの配列は { "items": [...], "total": <count>, "page": <page> } になり、content、data、body、objects、features などの一般的なラッパーキーは、必要に応じて items に引き上げられます。テキストレスポンスには、すべてのクライアントに返されるコンパクトな JSON ペイロードが引き続き含まれます。

ツール	説明
`harness_describe`	利用可能なリソースタイプ、操作、フィールドを検出します。API呼び出しは不要で、ローカルのレジストリメタデータを返します。
`harness_schema`	リソースの作成・更新に必要な正確なYAML/JSON Schema定義と例を取得します。パイプライン/テンプレートスキーマはバンドルされています。コネクタ、環境、サービス、シークレット、インフラストラクチャスキーマは、バンドルされたスナップショットまたはNG `/yaml-schema` から取得されるスコープ対応のエンティティスキーマです。`release_process` と `release_activity` のスキーマはRMG `/api/yamlSchema` からライブで取得されます。`path` による詳細なドリルダウンをサポートします。
`harness_list`	指定したタイプのリソースを、フィルタリング、検索、ページネーション付きで一覧表示します。
`harness_get`	識別子によって単一のリソースを取得します。
`harness_create`	新しいリソースを作成します。インラインおよびリモート（Git連携）パイプラインをサポートします。elicitation によるユーザー確認を求めます。
`harness_update`	既存のリソースを更新します。インラインおよびリモート（Git連携）パイプラインをサポートします。elicitation によるユーザー確認を求めます。
`harness_delete`	リソースを削除します。elicitation によるユーザー確認を求めます。破壊的操作です。
`harness_execute`	リソースに対してアクションを実行します（パイプラインの実行/再試行、Gitからのパイプラインインポート、フラグの切り替え、アプリの同期）。elicitation によるユーザー確認を求めます。パイプライン実行の場合は、以下のランタイム入力ワークフローを使用してください（`branch`/`tag`/`pr_number`/`commit_sha` の省略形展開をサポート）。
`harness_search`	単一のクエリでHarnessリソースタイプ全体を検索します。セマンティックルーティング（ローカル `all-MiniLM-L6-v2` ONNX埋め込み、384次元）を使用して、起動時にインデックス化された `knowledge` コーパスから関連するリソースタイプを予測します。通常、約163タイプから1〜8タイプに絞り込んでからスキャッターギャザーを実行します。セマンティック信頼度が低い場合は、フルキーワードのスキャッターギャザーにフォールバックします。ルーティングが機能した場合、レスポンスには `semantic_routed` と `types_skipped` が含まれます。新しいリソースタイプを検出可能にする方法については `docs/search-guidelines.md` を参照してください。
`harness_diagnose`	`pipeline`、`connector`、`delegate`、`gitops_application` リソースを診断します（エイリアス: `execution` -> `pipeline`、`gitops_app` -> `gitops_application`）。パイプラインの場合はステージ/ステップのタイミングと失敗の詳細を返し、コネクタ/デリゲート/GitOpsアプリの場合は対象を絞ったヘルスとトラブルシューティングのシグナルを返します。
`harness_status`	リアルタイムのプロジェクトヘルスダッシュボードを取得します。最近の実行、失敗率、ディープリンクが含まれます。

スキーマ検索ワークフロー

YAMLベースのリソースを作成・更新する前に harness_schema を使用して、エージェントが散文から推測する代わりに正確なフィールド名と制約をコピーできるようにします。

バンドルされたスキーマには pipeline、template、trigger、pipeline_v1、template_v1、inputSet_v1、overlayInputSet_v1、agent-pipeline が含まれます。
エンティティスキーマには connector、environment、service、secret、infrastructure が含まれます。これらはスコープ対応（account、org、または project）であり、選択したスコープで必要な場合は org_id/project_id が必要です。
リリース管理定義（release_process、release_activity）は、RMG /api/yamlSchema からライブのJSON Schemaを取得します（バンドルされていません）。組織またはプロジェクトにスコープする場合は scope、org_id、project_id を渡します。
ベンダー提供のエンティティスナップショットがランタイムアカウントと一致する場合は最初に使用され、それ以外の場合はツールはHarness NG /yaml-schema APIにフォールバックして結果をキャッシュします。
フィールド/セクションの概要については path を省略し、ネストされた定義を検査するにはドット区切りの path を渡します。

例:

{ "resource_type": "pipeline", "path": "pipeline.stages" }

{
  "resource_type": "connector",
  "scope": "project",
  "org_id": "default",
  "project_id": "payments"
}

HarnessエンティティYAMLスキーマが変更された場合、メンテナーは pnpm sync-entity-schemas でベンダー提供のエンティティスナップショットを更新できます。

ツール例

利用可能なリソースを検出:

{ "resource_type": "pipeline" }

アカウント内の組織を一覧表示:

{ "resource_type": "organization" }

組織内のプロジェクトを一覧表示:

{ "resource_type": "project", "org_id": "default" }

プロジェクト内のパイプラインを一覧表示:

{ "resource_type": "pipeline", "search_term": "deploy", "size": 10 }

特定のサービスを取得:

{ "resource_type": "service", "resource_id": "my-service-id" }

パイプラインを実行:

{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "my-pipeline",
  "inputs": { "tag": "v1.2.3" },
  "wait": true
}

フィーチャーフラグを切り替え:

{
  "resource_type": "feature_flag",
  "action": "toggle",
  "resource_id": "new_checkout_flow",
  "enable": true,
  "environment": "production"
}

すべてのリソースタイプを検索:

{ "query": "payment-service" }

IDによる実行の診断（サマリーモード — デフォルト）:

{ "execution_id": "abc123XYZ" }

Harness URLからの診断:

{ "url": "https://app.harness.io/ng/account/.../pipelines/myPipeline/executions/abc123XYZ/pipeline" }

コネクタ接続の診断:

{ "resource_type": "connector", "resource_id": "my_github_connector" }

デリゲートのヘルス診断:

{ "resource_type": "delegate", "resource_id": "delegate-us-east-1" }

GitOpsアプリケーションの診断（オプション付き）:

{
  "resource_type": "gitops_application",
  "resource_id": "checkout-app",
  "options": { "agent_id": "gitops-agent-1" }
}

パイプラインの最新の実行レポートを取得:

{ "pipeline_id": "my-pipeline" }

YAMLと失敗したステップログを含む完全診断モード:

{ "execution_id": "abc123XYZ", "summary": false }

ログを有効にしたサマリーモード（両方の利点）:

{ "execution_id": "abc123XYZ", "include_logs": true }

プロジェクトのヘルスステータスを取得:

{ "org_id": "default", "project_id": "my-project", "limit": 5 }

マイグレーションタイプでフィルタリングしたデータベーススキーマの一覧表示:

{ "resource_type": "database_schema", "migration_type": "Liquibase" }

スキーマのデータベースインスタンスを一覧表示:

{ "resource_type": "database_instance", "dbschema_id": "my_schema" }

スキーマとインスタンスの解決済みLLMオーサリングパイプラインを取得:

{ "resource_type": "database_llm_authoring_pipeline", "resource_id": "my_schema", "dbinstance_id": "prod_db" }

スキーマインスタンスのスナップショットオブジェクト名（例: テーブル）を一覧表示:

{
  "resource_type": "database_snapshot_object",
  "dbschema_id": "my_schema",
  "dbinstance_id": "prod_db",
  "object_type": "Table"
}

指定した名前付きオブジェクトの完全なスナップショットメタデータを取得:

{
  "resource_type": "database_snapshot_object",
  "resource_id": "prod_db",
  "params": {
    "dbschema_id": "my_schema",
    "object_type": "Table",
    "object_names": ["users", "orders"]
  }
}

パイプライン実行ワークフロー（推奨）

v0パイプラインの場合、このシーケンスを使用して実行時の入力エラーを減らします:

必要なランタイム入力を検出

harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
返されたテンプレートには、値が必要な <+input> プレースホルダーが表示されます。

入力戦略を選択

単純な変数: フラットなキーと値の inputs を渡します（例: {"branch":"main","env":"prod"}）。
複雑/構造的な入力: input_set_ids を使用します（CIコードベース/ビルドブロックとネストされたテンプレート入力はこの方法で最適に処理されます）。

CIコードベースの省略形キー（パイプライン実行のみ）:

省略形キー	展開された構造
`branch`	`build.type=branch`、`build.spec.branch=<value>`
`tag`	`build.type=tag`、`build.spec.tag=<value>`
`pr_number`	`build.type=PR`、`build.spec.number=<value>`
`commit_sha`	`build.type=commitSha`、`build.spec.commitSha=<value>`

制約: inputs.build がすでに存在する場合、省略形の展開はスキップされます（明示的な build が優先されます）。

実行を実行

harness_execute(resource_type="pipeline", action="run", resource_id="<pipeline_id>", ...)
YAMLをデフォルト以外のブランチからロードする必要があるGit連携パイプラインの場合、params.pipeline_branch を渡します（Harnessには branch として送信されます）。この明示的な定義セレクターは params.branch エイリアスよりも優先されます。inputs.branch はCIコードベースのブランチを個別に選択します:
```
{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "deploy_app",
  "params": { "pipeline_branch": "feature/new-stage" },
  "inputs": { "branch": "main" },
  "wait": true
}
```

オプション: 両方を組み合わせる

基本形状には input_set_ids を使用し、単純なオーバーライドには inputs を使用します。

v1パイプラインの場合:

harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>") を取得します。 Git連携パイプラインの場合、branch_name、connector_ref、repo_name を params を通じて渡します。
返された各 inputs[].details.name を harness_execute.inputs のトップレベルキーとして使用します。
harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}) を実行します。サーバーはこれらの値を inputs: YAMLルートの下にラップし、APIの inputs_yaml ボディを送信します。

必須フィールドが未解決の場合、ツールは期待されるキーと推奨される入力セットを含む事前フライトエラーを返します。利用可能なショートハンドマッピングは、harness_describe(resource_type="pipeline")（executeActions.run.inputShorthands）で確認できます。

動的パイプライン実行

エージェントまたは外部システムが実行時に完全なv0パイプラインYAMLを生成し、それを既存のHarnessパイプラインシェルに対して実行する必要がある場合は、pipeline_dynamic_execution.runを使用します。これは通常のpipeline.runの代替ではありません。保存済みのv0パイプラインがすでに存在し、アカウントレベルとパイプラインレベルの動的実行を許可が有効であり、呼び出し元がパイプラインに対する編集権限と実行権限を持っている必要があります。

{
  "resource_type": "pipeline_dynamic_execution",
  "action": "run",
  "resource_id": "deploy_app",
  "body": {
    "yaml": "pipeline:\n  identifier: deploy_app\n  name: Deploy App\n  stages: []"
  },
  "params": {
    "module_type": "CD",
    "notes": "agent-generated dynamic run",
    "notify_only_user": true
  }
}

制約事項：

bodyは、yamlフィールドを持つオブジェクトである必要があります。生の文字列本文は、公開されているharness_executeスキーマによって拒否されます。
body.yamlは、YAML文字列またはJSONパイプラインオブジェクトのいずれかです。JSONはリクエスト前にYAMLにシリアル化されます。
ランタイムの<+input>プレースホルダーは、このAPIでは解決されません。完全に解決されたYAMLを送信してください。
入力セット、選択的ステージ実行、再試行、およびトリガーは、動的実行エンドポイントではサポートされていません。
アクションはhigh_writeであり、通常の確認/自動承認パスを使用します。レスポンスはAPIエンベロープを{ "execution_id": "...", "status": "..." }に投影し、スコープデータが利用可能な場合はopenInHarness実行リンクを含みます。

Harnessが実行を有効でないとして拒否した場合は、アカウントレベルの動的実行を許可設定と、パイプライン -> 詳細オプション -> 動的実行設定の下にあるパイプラインレベルのトグルを両方確認してください。

実行入力フォレンジック

実行後にexecution_inputsを使用して、特定の実行を生成したマージされた入力YAMLを検査します。これは、障害が入力セットのマージ、Gitバックアップの入力セットブランチ、または実行ページだけから再構築するのが難しいトリガー/ランタイム値に依存する場合に役立ちます。

{
  "resource_type": "execution_inputs",
  "resource_id": "PLAN_EXECUTION_ID",
  "params": {
    "resolve_expressions": true,
    "resolve_expressions_type": "RESOLVE_ALL_EXPRESSIONS"
  }
}

getレスポンスは以下に投影されます：

executionId - resource_idからのプラン実行ID。
inputSetYaml - 実行に使用されたマージされたランタイム入力YAML、またはnull。
inputSetTemplateYaml - 実行時の入力テンプレート、またはnull。
resolvedYaml - resolve_expressions=trueの場合の式解決済みYAML、それ以外の場合は通常null。
inputSetDetails - 貢献した保存済み入力セットを{ identifier, name }ペアとして。
inputSetBranchName - Gitバックアップの入力セットのソースブランチ、またはnull。

execution_inputsは取得専用で読み取りリスクです。resolve_expressionsが省略された場合、サーバーはAPIクエリパラメータを省略し、HarnessはデフォルトのUNKNOWN解決モードを使用します。

パイプライン実行待機モード

pipeline.run、pipeline.retry、およびpipeline_v1.runの場合、wait: trueを渡して、サーバーが実行が終了ステータスに達するまでポーリングできるようにします。これにより、パイプラインの起動とステータスチェックを1つのツール呼び出しで行うことができ、クライアントやLLMにポーリングループを実行させる必要がありません。

{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "deploy_app",
  "inputs": { "branch": "main" },
  "wait": true,
  "wait_timeout_seconds": 900,
  "wait_poll_interval_seconds": 5
}

待機モードの動作：

デフォルトのタイムアウトは600秒です。許可される範囲は10秒から7200秒です。
初期ポーリング間隔はデフォルトで3秒で、1.5倍ずつバックオフし、最大30秒で上限に達します。
成功または失敗時に、レスポンスにはexecution_id、execution_status、execution_terminal、execution_elapsed_ms、execution_poll_countなどのフィールドが含まれます。
タイムアウトが発生した場合、元のトリガーはまだ成功しています。レスポンスにはexecution_timed_out: trueと_wait.hintが最後に観測されたステータスとともに含まれます。
トリガー成功後にポーリングが失敗した場合、レスポンスには_wait.errorと再チェックのヒントが含まれます。最初の実行が実行中でないことを確認しない限り、パイプラインを盲目的に再実行しないでください。
失敗した終了ステータスには、harness_diagnose(resource_type="execution", options={execution_id: "..."})を指す_diagnose_hintが含まれます。

AI DevOpsエージェントにパイプラインの作成を依頼する：

{
  "prompt": "Create a pipeline that builds a Go app with Docker and deploys to Kubernetes",
  "action": "CREATE_PIPELINE"
}

自然言語でサービスを更新する：

{
  "prompt": "Add a sidecar container for logging",
  "action": "UPDATE_SERVICE",
  "conversation_id": "prev-conversation-id",
  "context": [{ "type": "yaml", "payload": "<existing service YAML>" }]
}

パイプラインストレージモード

Harnessパイプラインは3つの方法で保存できます：

モード	説明	使用時期
インライン	Harnessに保存されたパイプラインYAML	デフォルト。最も簡単なセットアップで、Gitは不要です。
リモート（外部Git）	GitHub、GitLab、Bitbucketなどに保存されたパイプラインYAML	外部プロバイダーでGitバックアップのパイプライン・アズ・コードを使用するチーム。
リモート（Harness Code）	Harness Codeリポジトリに保存されたパイプラインYAML	Harnessの組み込みGitホスティングを使用するチーム。

インラインパイプラインを作成する（デフォルト）：

// harness_create
{
  "resource_type": "pipeline",
  "body": {
    "yamlPipeline": "pipeline:\n  name: My Pipeline\n  identifier: my_pipeline\n  stages:\n    - stage:\n        name: Build\n        type: CI\n        spec:\n          execution:\n            steps:\n              - step:\n                  type: Run\n                  name: Echo\n                  spec:\n                    command: echo hello"
  }
}

リモートパイプラインを作成する（外部Git — 例：GitHub）：

// harness_create
{
  "resource_type": "pipeline",
  "body": {
    "yamlPipeline": "pipeline:\n  name: Deploy Service\n  identifier: deploy_service\n  stages: []"
  },
  "params": {
    "store_type": "REMOTE",
    "connector_ref": "my_github_connector",
    "repo_name": "my-repo",
    "branch": "main",
    "file_path": ".harness/deploy-service.yaml",
    "commit_msg": "Add deploy pipeline via MCP"
  }
}

リモートパイプラインを作成する（Harness Code — コネクタ不要）：

// harness_create
{
  "resource_type": "pipeline",
  "body": {
    "yamlPipeline": "pipeline:\n  name: Build App\n  identifier: build_app\n  stages: []"
  },
  "params": {
    "store_type": "REMOTE",
    "is_harness_code_repo": true,
    "repo_name": "product-management",
    "branch": "main",
    "file_path": ".harness/build-app.yaml",
    "commit_msg": "Add build pipeline via MCP"
  }
}

リモートパイプラインを更新する：

// harness_update
{
  "resource_type": "pipeline",
  "resource_id": "deploy_service",
  "body": {
    "yamlPipeline": "pipeline:\n  name: Deploy Service\n  identifier: deploy_service\n  stages:\n    - stage:\n        name: Deploy\n        type: Deployment"
  },
  "params": {
    "store_type": "REMOTE",
    "connector_ref": "my_github_connector",
    "repo_name": "my-repo",
    "branch": "main",
    "file_path": ".harness/deploy-service.yaml",
    "commit_msg": "Update deploy pipeline via MCP",
    "last_object_id": "abc123",
    "last_commit_id": "def456"
  }
}

外部Gitリポジトリからパイプラインをインポートする：

// harness_execute
{
  "resource_type": "pipeline",
  "action": "import",
  "params": {
    "connector_ref": "my_github_connector",
    "repo_name": "my-repo",
    "branch": "main",
    "file_path": ".harness/existing-pipeline.yaml"
  },
  "body": {
    "pipeline_name": "Existing Pipeline",
    "pipeline_description": "Imported from GitHub"
  }
}

Harness Codeリポジトリからパイプラインをインポートする：

// harness_execute
{
  "resource_type": "pipeline",
  "action": "import",
  "params": {
    "is_harness_code_repo": true,
    "repo_name": "product-management",
    "branch": "main",
    "file_path": ".harness/existing-pipeline.yaml"
  },
  "body": {
    "pipeline_name": "Existing Pipeline"
  }
}

コネクタを作成する：

{
  "resource_type": "connector",
  "body": { "connector": { "name": "My Docker Hub", "identifier": "my_docker", "type": "DockerRegistry" } }
}

トリガーを削除する：

{
  "resource_type": "trigger",
  "resource_id": "nightly-trigger",
  "pipeline_id": "my-pipeline"
}

パイプラインの入力セットを一覧表示する：

{
  "resource_type": "input_set",
  "pipeline_id": "my-pipeline"
}

特定の入力セットを取得する：

{
  "resource_type": "input_set",
  "resource_id": "prod-inputs",
  "pipeline_id": "my-pipeline"
}

入力セットを作成する：

{
  "resource_type": "input_set",
  "pipeline_id": "my-pipeline",
  "body": "inputSet:\n  name: Production Inputs\n  identifier: prod_inputs\n  pipeline:\n    identifier: my-pipeline\n    variables:\n      - name: env\n        type: String\n        value: production"
}

入力セットを更新する：

{
  "resource_type": "input_set",
  "resource_id": "prod_inputs",
  "pipeline_id": "my-pipeline",
  "body": "inputSet:\n  name: Production Inputs\n  identifier: prod_inputs\n  pipeline:\n    identifier: my-pipeline\n    variables:\n      - name: env\n        type: String\n        value: production\n      - name: replicas\n        type: String\n        value: \"3\""
}

入力セットを削除する：

{
  "resource_type": "input_set",
  "resource_id": "prod_inputs",
  "pipeline_id": "my-pipeline"
}

リソースタイプ

41のツールセットにわたって255のリソースタイプが編成されています。各リソースタイプは、CRUD操作のサブセットとオプションの実行アクションをサポートしています。

プラットフォーム

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`organization`	x	x	x	x	x
`project`	x	x	x	x	x

パイプライン

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`pipeline`	x	x	x	x	x	`run`、`retry`
`pipeline_v1` （アルファ）	x	x	x	x	x	`run`
`pipeline_dynamic_execution`						`run`
`execution`	x	x				`interrupt`
`execution_inputs`		x
`trigger`	x	x	x	x	x
`pipeline_summary`		x
`input_set`	x	x	x	x	x
`runtime_input_template`		x
`runtime_input_template_v1`		x
`pipeline_resolved_yaml`		x
`approval_instance`	x					`approve`、`reject`

パイプラインYAMLリソースタイプは両方とも、パイプラインズツールセットが有効な場合に利用可能です。HARNESS_PIPELINE_VERSIONとHTTPのx-harness-pipeline-version初期化ヘッダーがデフォルトのバージョン設定を選択します。これらは他のバージョンを非表示にしません。

AIエージェント

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`agent`	x	x	x	x	x
`agent_run`	x

サービス

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`service`	x	x	x	x	x

環境

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`environment`	x	x	x	x	x	`move_configs`

コネクタ

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`connector`	x	x	x	x	x	`test_connection`
`connector_catalogue`	x

インフラストラクチャ

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`infrastructure`	x	x	x	x	x	`move_configs`

シークレット

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`secret`	x	x

実行ログ

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`execution_log`		x

監査証跡

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`audit_event`	x	x

デリゲート

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`delegate`	x	x
`delegate_token`	x	x	x		x	`revoke`、`get_delegates`

コードリポジトリ

リソースタイプ	一覧	取得	作成	更新	削除	実行アクション
`repository`	x	x	x	x
`branch`	x	x	x		x
`commit`	x	x	x			`diff`、`diff_stats`
`file_content`	x	x				`blame`
`tag`	x		x		x
`repo_rule`	x	x
`space_rule`	x	x

commitの作成は、クローンなしでHarness Code APIを通じて直接1つ以上のファイルアクションをコミットします。body.title、body.branch、body.actionsを渡します。各アクションはCREATE、UPDATE、DELETE、またはMOVEであり、UPDATEには現在のblob SHAが必要です。

file_contentの一覧は、refのすべてのパスを返します。取得はファイルまたはディレクトリのコンテンツを返します（リポジトリルートの場合はpathを省略するか空で渡します。ネストされたパスはスラッシュを保持します）。git_refを省略すると、リポジトリのデフォルトブランチを使用します。mainを推測しないでください。

アーティファクトレジストリ

リソースタイプ	一覧	取得
`registry`	x	x
`artifact`	x
`artifact_version`	x
`artifact_file`	x

ファイルストア

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`file_store`	x	x	x	x	x	`list_children`

file_store は、汎用ツールを通じて Harness ファイルストアのファイルとフォルダーを管理します。アカウント、組織、プロジェクトのスコープをサポートします。resource_scope="account"|"org"|"project" を渡すか、Harness ファイルストアの URL を貼り付けて、サーバーがスコープと ID を導出できるようにします。

一般的な呼び出し:

# List the account-level File Store.
harness_list(resource_type="file_store", resource_scope="account")

# Create a folder at the current scope root.
harness_create(resource_type="file_store", body={
  name: "scripts",
  type: "FOLDER",
  parent_identifier: "Root"
})

# Upload a UTF-8 script file. Use content_base64 instead for binary data.
harness_create(resource_type="file_store", body={
  name: "deploy.sh",
  type: "FILE",
  parent_identifier: "Root",
  content: "#!/usr/bin/env bash\n./deploy",
  mime_type: "text/x-shellscript",
  file_usage: "SCRIPT"
})

# Rename metadata without replacing file content.
harness_update(resource_type="file_store", resource_id="deploy_script", body={
  name: "deploy-prod.sh",
  type: "FILE",
  parent_identifier: "Root"
})

# List first-level children of a folder. This is a read-risk execute action.
harness_execute(resource_type="file_store", action="list_children",
  resource_id="scripts_folder", params={folder_name: "scripts"})

マルチパートボディの制約:

作成/更新は JSON body を受け入れ、それを /ng/api/file-store 用の multipart/form-data に変換します。
name、type（FILE または FOLDER）、および parent_identifier は必須です。選択したスコープのルートにはリテラル "Root" のみを使用します。
FILE の作成には、content（UTF-8 文字列）または content_base64（有効な非空の base64）のいずれか 1 つだけが必要です。FILE の更新では、メタデータのみの更新のためにコンテンツを省略するか、コンテンツを置き換えるためにコンテンツフィールドを 1 つだけ指定できます。
FOLDER の作成/更新では、content と content_base64 を省略する必要があります。
オプションの file_usage は、MANIFEST_FILE、CONFIG、または SCRIPT である必要があります。description、mime_type、path、tags などのオプションのスカラーメタデータは文字列である必要があります。
アップロードコンテンツは 100 MB に制限されています。確認プロンプトでは、content、content_base64、contentBase64 のプレビューを編集してから確認を求めます。

list_children は、短縮形（resource_id と params.folder_name、または params.file_store_id/params.folder_identifier と params.folder_name）または、identifier、name、type: "FOLDER" を含む完全な FileStoreNode body のいずれかを受け入れます。完全なボディは Harness の camelCase parentIdentifier を使用します。短縮形は params.parent_identifier を使用できます。

テンプレート

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`template`	x	x	x	x	x

テンプレート操作は、Harness テンプレートサービスのパス（/template/api/templates...）を使用します。作成と更新には、body.template_yaml または body.yaml に完全なテンプレート YAML 文字列が必要です。version_label は更新/削除の特定のバージョンを対象とし、version_label なしで削除するとすべてのバージョンが削除されます。

ダッシュボード

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`dashboard`	x	x
`dashboard_data`		x

データベース DevOps

リソースタイプ	一覧	取得	作成	更新	削除
`database_schema`	x	x	x	x	x
`database_instance`	x	x	x	x	x
`database_snapshot_object`	x	x
`database_llm_authoring_pipeline`		x

Infrastructure as Code 管理（IaCM）

IaCM リソースはデフォルトで有効になっており、ほとんどがプロジェクトスコープです。iacm_workspace から始めてワークスペース識別子を見つけ、その workspace_id をワークスペースリソース、コスト、アクティビティ差分に使用します。再利用可能な変数セットには、アカウント、組織、またはプロジェクトスコープで iacm_variable_set を使用します。プロバイダーレジストリはアカウントスコープです。

iacm_module は、アカウント、組織、プロジェクトのスコープにまたがります。デフォルトはアカウントレジストリです。すべての操作（一覧、取得、作成、更新）は同じ scope_org / scope_project クエリパラメータを送信するため、作成したモジュールは作成したスコープで検出可能です。resource_scope="account" | "org" | "project" と org_id/project_id でスコープを選択します。スコープ設定はオプトインです。resource_scope が省略された場合、org_id/project_id は明示的に渡した場合にのみ適用されます。設定済みの HARNESS_ORG/HARNESS_PROJECT デフォルトは適用されないため、環境のプロジェクト設定によってアカウントモジュールがプロジェクトの下に静かに登録されることはありません。モジュールボディ自体の org/project フィールドは Git コネクタを特定するもので、この可視性スコープとは無関係です。

iacm_workspace の作成/更新は { policy_evaluation } のみを返します。ワークスペースを取得するには harness_get でフォローアップします。iacm_variable_set と iacm_module の作成/更新はリソース自体を返します。iacm_provider の作成は { id } のみを返します。harness_get でフォローアップします。更新はバージョン指向のみです（POST/PUT /providers/{id}/version）。メタデータ PUT はありません。バージョンの書き込みは空のボディを返す場合があります。HarnessClient はそれを { status: "SUCCESS", message: "No content" } に正規化します。

変数セットの更新は HTTP PUT で、コレクション全体を置き換えます。常に最初に harness_get を実行し、次に完全な目的のボディを PUT します（更新時には terraform_variables / environment_variables が必須です。省略または空にするとコネクタと変数ファイルがクリアされます）。モジュールの更新も PUT です。オプションフィールドには get-then-put を推奨します。書き込みは medium_write であり、確認が必要です（確認プロンプトまたは confirm: true）。

変数セットとプロバイダーレジストリの RBAC（iac_variableset_*、iac_providerregistry_*）は現在 Harness では Experimental です。iac-server が強制を有効にするまで、アクセスチェックは常に許可されます。モジュールレジストリの RBAC（iac_registry_view / iac_registry_edit）は Active で強制可能です。MCP は常に呼び出し元の PAT/SAT を変更せずに転送します。

リソースタイプ	一覧	取得	作成	更新
`iacm_workspace`	x	x	x	x
`iacm_variable_set`	x	x	x	x
`iacm_resource`	x
`iacm_module`	x	x	x	x
`iacm_provider`	x	x	x	x
`iacm_workspace_costs`	x
`iacm_activity_resource_change`	x

典型的なワークフロー:

harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") でワークスペースを見つけます。
iacm_workspace で harness_create / harness_update を使用して、ゼロからまたはテンプレート（associated_template）から作成するか、既存のワークスペースを更新します。応答は { policy_evaluation } のみです。
harness_get(resource_type="iacm_workspace", workspace_id="...") で作成/更新されたワークスペースを取得します。
iacm_variable_set で harness_list / harness_create / harness_update を使用して、再利用可能な Terraform/env 変数セットを操作します（オプションで resource_scope を使用）。応答は VariableSet リソースです。
iacm_module で harness_list / harness_create / harness_update を使用してモジュールレジストリを操作します（name + system が必須。組織またはプロジェクトスコープのモジュールには org_id/project_id を指定して resource_scope を追加）。応答はモジュールリソースです。
iacm_provider で harness_list / harness_create / harness_update を使用してアカウントプロバイダーレジストリを操作します（作成には body.type が必須。作成は { id } のみを返すため、次に harness_get を実行。更新はバージョンのみを作成/更新します）。バージョンの更新は空の成功を返す場合があります。
harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") で Terraform リソース、出力、データソースを検査します。
harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") で実行ごとのコストエントリを確認します。
harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") でプラン、適用、または破棄アクティビティの前後のリソース差分を検査します。

IaCM の一覧応答は、page_count を現在のページのみのカウントとして公開します（ページ分割されていない iacm_variable_set を除く）。has_more が true の場合、次の 1 ベースのページを要求し続け、合計が必要な場合はページカウントを合計します。

内部開発者ポータル（IDP）

リソースタイプ	一覧	取得	アクション実行
`idp_entity`	x	x
`scorecard`	x	x
`scorecard_check`	x	x
`scorecard_stats`		x
`scorecard_check_stats`		x
`idp_score`	x	x
`idp_workflow`	x		`execute`
`idp_tech_doc`	x

プルリクエスト

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`pull_request`	x	x	x	x		`close`、`merge`
`pr_reviewer`	x		x			`submit_review`
`pr_comment`			x	x	x
`pr_check`	x
`pr_activity`	x

明示的なクローズ操作には harness_execute(resource_type="pull_request", action="close", ...) を使用します。harness_update は body.state（open または closed）も受け入れ、状態変更を専用の Harness Code PR 状態エンドポイントにルーティングします。タイトル/説明の編集は別の更新呼び出しで送信します。

PR コメントの読み取りには harness_list(resource_type="pr_activity", filters={type: ["comment", "code-comment"]}, ...) を使用します。コメントの書き込み操作には pr_comment を使用します。

リリース管理

リリース管理（RMG）リソースはデフォルトで有効です。定義リソース（release_process、release_activity）は、body.yaml を使用した一覧/取得/作成/更新/削除をサポートします。作成/更新の前に harness_schema(resource_type="release_process"|"release_activity") を呼び出します。実行リソースは実行中のリリースを監視します。ほとんどの一覧操作には release_id（harness_list resource_type=release からの UUID、または identifier-1.0.0-abc などの UI URL スラッグ）が必要です。RMG リリース URL を harness_list に貼り付けると、release_id が自動入力されます。

RMG 呼び出しは、Harness-Account ヘッダーによるアカウントスコープ設定で ${HARNESS_BASE_URL}/gateway/rmg を使用します。組織/プロジェクトスコープは、org_id/project_id が指定されている場合、ヘッダーベースのスコープ設定を使用します。release_execution_phase は一覧のみです。フェーズ入力/出力リソースで harness_get を呼び出すときは、各フェーズ項目の identifier フィールドを params.phase_identifier として使用します（release_execution_phase 自体で harness_get を呼び出さないでください）。リリース一覧の status フィルタリングは、現在のページのみにクライアント側で適用されます。結果が複数ページにまたがる可能性がある場合は、同じフィルタでページングを続けます。

リソースタイプ	一覧	取得	作成	更新	削除
`release_process`	x	x	x	x	x
`release_activity`	x	x	x	x	x
`release`	x	x
`release_execution_phase`	x
`release_execution_task`	x
`release_execution_activity`	x
`release_input`		x
`release_execution_phase_input`		x
`release_execution_phase_output`		x
`release_execution_activity_input`		x
`release_execution_activity_output`		x

一般的なワークフロー:

harness_list(resource_type="release_process", org_id="...", project_id="...") を使用してオーケストレーションプロセス定義を検出します。
作成/更新の前に harness_schema(resource_type="release_process")（または release_activity）を実行します。その後、body.yaml を指定して harness_create / harness_update を実行します。
harness_list(resource_type="release", org_id="...", project_id="...") を使用して、アクティブまたは最近のリリースを検索します（デフォルトは30日間の遡及期間。オプションで filters.status、filters.search_term、filters.days_back を指定可能）。
リリースの詳細は harness_get(resource_type="release", release_id="...") で取得します。
フェーズのステータスは harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) で確認します。release_execution_task と release_execution_activity には同じ release_id を使用します。
release_input、release_execution_phase_input、release_execution_phase_output、release_execution_activity_output、または release_execution_activity_input に対して、各リソースに記載されている release_id に加えて params.phase_identifier / params.activity_identifier / activity_execution_id を使用して harness_get を実行します。

Vibe

デフォルトで有効な vibe ツールセットは、${HARNESS_BASE_URL}/vibe/v1 配下の Vibe Orchestrator BFF コントラクトをカバーします。既存の Harness 接続とアカウントヘッダーを使用し、リクエストボディにアカウント/組織/プロジェクトのクエリパラメータやスコープフィールドを追加しません。チームは Harness API キー認証（PAT/SAT）を使用して Vibe フローを検証したため、デフォルトセッションにオプトイン設定は不要です。厳選された OpenAPI はベアラー/セッション認証を文書化しています。サーバーの OAuth モードは現在のセッションのベアラートークンを転送します。自動回帰テストは両方のヘッダーパスを検証します。ゲートウェイ認証はターゲット環境の設定に依存します。

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`vibe_project`			x			`prepare`、`deploy`
`vibe_app_lifecycle`		x				`events`

API は2つの取り込みパスをサポートしています。これらの API ネイティブなリクエスト形状を維持してください:

コーディングエージェントが利用可能なソース	API フロー
GitHub リポジトリのリンク/コネクタ	`resource_type="vibe_project"` と `body.mode` に加えてモード固有のフィールドを指定して `harness_create` を実行します。コントラクトは `github_link` と `github_connector` を定義していますが、その URL、ブランチ、コネクタのフィールド形状は定義していません。これらのフィールドはマッピングを独自に作成せずにバックエンドに転送されます。
ZIP ファイル	アプリ名とファイルメタデータを指定して `prepare` を呼び出し、返された署名付きターゲットにバイトをアップロードしてから、`deploy` を呼び出します。
ローカルソースディレクトリ	コーディングエージェントは、意図したワークスペースのソースをローカルで ZIP にアーカイブし、ZIP フローに従います。ローカルパスや会話コンテキストは API でサポートされるソースアップロードではありません。

ディレクトリをパッケージ化する際は、ビルドに必要なソース、マニフェスト、ロックファイル、設定、および未コミットの意図した編集を含めてください。資格情報、.git、インストール済みの依存関係、生成されたアーティファクトは除外してください。パッケージ化と署名付きアップロードはファイルにアクセスできる場所で行われます。ホスト型 MCP サーバーはコーディングエージェントのローカルディレクトリを読み取ることはできません。

既存の ZIP の場合、アップロードを準備します:

{
  "resource_type": "vibe_project",
  "action": "prepare",
  "body": {
    "name": "demo-app",
    "file": {
      "path": "app.zip",
      "size_bytes": 12345,
      "content_type": "application/zip"
    }
  }
}

これを harness_execute に渡します。サイズは実際の ZIP を記述する必要があります。size_bytes、content_type、md5 はオプションであり、null 許容です。追加の準備フィールドは、OpenAPI で許可されているように、バックエンド検証のために保持されます。準備処理は projectId、sourceId、upload を返し、各ファイルの uploadUrl、method、headers、expiresAt を含みます。その署名付き URL、メソッド、ヘッダーを使用してファイルのバイトを直接アップロードします。URL を正確に保持し、ストレージリクエストに Harness 資格情報を追加しないでください。準備アクションはローカルファイルを読み取ったりアップロードしたりしません。

アップロードが成功したら、明示的にデプロイします:

{
  "resource_type": "vibe_project",
  "action": "deploy",
  "resource_id": "<projectId returned by prepare>"
}

JSON インポートの場合は、返された id を代わりに使用します。デプロイは body: {"project_id": "<Vibe app id>"} または params.app_id も受け入れます。API ワイヤーフィールドは snake_case の project_id ですが、prepare は camelCase の projectId を返します。汎用ツールのトップレベル project_id は Harness スコープ識別子であり、Vibe アプリ ID として使用されることはありません。インポートと準備はアプリ/ソースを作成しますが、どちらもデプロイを開始しません。書き込みは自動的に再試行されず、デプロイは既存の高リスク確認ポリシーを使用します。

harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>") で進行状況を読み取ります。アプリ URL、実行ステージ、サブステップ、失敗、ログ行、ビルドアナライザーの詳細が保持されます。events 実行アクションは resource_id または params.app_id を受け入れ、SSE エンドポイントを有限バッチとして消費します: 最大20件の JSON イベントまたは接続後5秒、1 MiB の応答制限付き。これらの制限は Vibe エンドポイントに属します。接続の HARNESS_API_TIMEOUT_MS は接続とストリーム消費をまとめて制限します。期限切れはタイムアウトエラーを返します。完了したバッチは events と stop_reason（end、event_limit、または duration_limit）を返し、ストリームを閉じます。初期接続失敗もストリーム切断も再試行されません。イベントは一時的な差分であり、文書化されたリプレイカーソルはありません。信頼できるスナップショットにはライフサイクル取得を使用してください。両方のライフサイクル読み取りは読み取り専用モードで利用できます。

フィーチャーフラグ

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`fme_workspace`	x
`fme_environment`	x	x	x	x	x
`fme_feature_flag`	x	x	x	x	x	`kill`、`restore`、`reallocate`、`archive`、`unarchive`
`fme_feature_flag_definition`	x	x	x	x	x	`kill`、`restore`、`reallocate`
`fme_rollout_status`	x
`fme_rule_based_segment`	x	x	x		x
`fme_rule_based_segment_definition`	x			x		`enable`、`disable`、`change_request`
`fme_traffic_type`	x
`fme_identity`			x	x
`fme_standard_segment`	x	x
`fme_segment_keys`	x			x
`fme_segment`	x	x	x	x	x
`fme_segment_definition`	x	x	x	x	x	`list_keys`、`add_keys`、`remove_keys`
`fme_metric`	x	x	x	x	x
`fme_event_type`	x	x

FME（Split.io）リソース — fme_* リソースはデュアルモードスコーピングをサポートしています: レガシー呼び出しは workspace_id を渡して Split.io API（api.split.io）を呼び出します。新しい呼び出しは org_id+project_id を一緒に渡して、Harness ネイティブエンドポイント（標準の HARNESS_API_KEY/HARNESS_BASE_URL、他のすべての harness_* リソースと同じ認証）を代わりに呼び出します。同じ呼び出しで workspace_id と org_id/project_id の両方を渡すか、org_id を project_id だけで混在させることはエラーです。呼び出しごとに1つのモードを選択してください。以下のすべての操作は、リソースが Harness ネイティブ専用とマークされていない限り、変更なしでレガシーモードで利用できます。Harness ネイティブモードのカバレッジは現在より狭くなっています:

fme_workspace — Harnessネイティブの同等機能はなし。レガシーのみ（workspace_id 値の検出に使用）。
fme_environment — デュアルモードの list（workspace_id または org_id+project_id）。get/create/update/delete は Harnessネイティブのみ（/fme/api/v4/environments）— MCPにはこれらの操作に対する workspace_id 契約は存在しなかった。ネイティブのリストはオプションの offset/limit を使用（最大100件。harness_list size は limit にマッピング）。エンベロープの {data, limit, offset, totalCount} は items/total に昇格。ネイティブの作成/更新は isProduction を使用（production はエイリアスとして受け入れ）。ネイティブの更新はJSON Merge Patch。name と isProduction はクリア不可。名前は最大15文字。
fme_feature_flag — デュアルモード。両ブランチとも完全に配線済み。Harnessネイティブ（org_id+project_id）：list/get/create/delete は /fme/api/v4/feature-flags にヒット（create のボディ：name、trafficType、オプションの description/tags/owners、CreateFeatureFlagRequest に従う）。update は /fme/api/v4/feature-flags/{name} にマージパッチを送信。archive/unarchive は /fme/api/v4/feature-flags/{name}/archive|unarchive にヒット（オプションの comment のみ — title なし、ArchiveUnarchiveRequest に従う）。kill/restore/reallocate は /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate にヒットし、environment_id をクエリパラメータとして使用（オプションの comment/title、FeatureFlagDefinitionActionRequest に従う）。
fme_feature_flag_definition — get/create/update はデュアルモードのまま（workspace_id または org_id+project_id）。list/delete/kill/restore/reallocate は Harnessネイティブのみ（org_id+project_id）— MCPにはこれらの操作に対する workspace_id 契約は存在しなかった。ネイティブのリストは feature_flag_name を必須とし、offset/limit を使用（デフォルト100、最大100）。environment_id は受け取らない。削除と実行は environment_id を必須とする。Kill/restore/reallocate は fme_feature_flag と同じアクション。取得/作成/更新のボディはレガシーと一致（treatments、defaultTreatment、defaultRule、オプションの rules/baselineTreatment/trafficAllocation/comment）。さらに Harnessネイティブモードではオプションの title が追加。ネイティブの更新はJSON Merge Patch。
fme_rollout_status — デュアルモードの list。org_id+project_id（推奨）または非推奨の workspace_id を渡す。ネイティブのページネーションは offset/limit を使用（最大100件。harness_list size は limit にマッピング）。結果は items/total に昇格。各項目には id、name、オプションの description がある。
fme_rule_based_segment — （非推奨 — fme_segment を参照。）Harnessネイティブモードはすべての操作で拒否される（list/get/create/delete）— 代わりに fme_segment を使用。このリソースはレガシーの workspace_id 契約のみをサポート。
fme_rule_based_segment_definition — （非推奨 — fme_segment_definition を参照。）Harnessネイティブモードはすべての操作/アクションで拒否される（list/update/enable/disable/change_request）— 代わりに fme_segment_definition を使用（そこには enable/disable/change_request の同等機能はなし）。このリソースはレガシーの workspace_id/environment_id 契約のみをサポート。
fme_traffic_type — デュアルモードの list。org_id+project_id（推奨）または非推奨の workspace_id を渡す。ネイティブのページネーションは offset/limit を使用（最大100件。harness_list size は limit にマッピング）。結果は items/total に昇格。各項目には id と name がある（displayAttributeId なし）。
fme_identity — create/update は、org_id+project_id が一緒に渡された場合、まだ実装されていない。それ以外は通常のレガシー呼び出しとして処理される。
fme_standard_segment — 非推奨。レガシーの workspace_id は引き続き Split v2 にヒット。Harnessネイティブは拒否 — fme_segment を使用。
fme_segment_keys — list/update はレガシーのまま（workspace_id / environment_id+segment_name）。Harnessネイティブ（org_id+project_id）は拒否 — fme_segment_definition の実行 list_keys/add_keys/remove_keys を使用。
fme_segment — ネイティブのみ（org_id+project_id）。CRUD。list/get/update/delete は segment_type を必須とする：STANDARD | LARGE | RULE_BASED。作成ボディ：name、trafficType、segmentType。オプション：description、tags、owners。
fme_segment_definition — ネイティブのみ。CRUD に加えて実行 list_keys/add_keys/remove_keys。更新は説明のみ。キーが残っている間、削除は hasDependents で失敗する。
fme_metric — Harnessネイティブのみ（レガシーの workspace_id サポートなし）。list/get/create/update/delete は /fme/api/v4/metrics に配線済み（list の harness_list size は limit にマッピング）。create は、バックエンドの CreateMetricRequest がオプションのまま（デフォルト PER）でも spread を必須とする — MCP側のみのより厳格な契約。省略すると RATE メトリクスのセマンティクスが暗黙的に変わるため。update はJSON Merge Patch。name/trafficType は不変であり受け入れられない。delete は恒久的なハード削除（アーカイブ/復元なし）— destructive に分類。
fme_event_type — Harnessネイティブのみ（レガシーの workspace_id サポートなし）。読み取り専用：list/get は /fme/api/v4/event-types に配線済み。id はイベント名。直近30日以内にイベントがあるイベントタイプのみ表示。get は、リクエスト元ワークスペースのトラフィックタイプのスコープ外のイベントタイプ、または30日以上アイドル状態のイベントタイプに対して404を返す。リストのフィルター：name（部分文字列）、traffic_type（IDまたは名前）、offset/limit（harness_list size は limit にマッピング）。fme_metric の baseEventTypes/filterEventType または event_type_ids フィルターでIDを推測する代わりに、これを使用して実際のイベントタイプIDを検出する。

シングルユーザー/セルフホストモードでは、レガシーモードの認証は HARNESS_FME_API_KEY のBearerトークンを使用し、非プレースホルダーの HARNESS_API_KEY にフォールバックする。HARNESS_FME_API_KEY はレガシーのSplit管理者キーまたはFME資格のあるHarness PAT/SATの場合があるが、multi-user モードでは拒否されるため、共有デプロイメントは各セッションユーザーの資格情報を上書きできない。HarnessプラットフォームAPI用のホステッドOAuth/サービスルーティング資格情報は、直接のSplit.ioリクエストを認証しない。fme_feature_flag はレガシーモードで完全なライフサイクル管理をサポート：作成（traffic_type_id を必須）、リスト、取得、メタデータ更新、削除、および kill/restore/reallocate/archive/unarchive の実行アクション。fme_traffic_type を使用してトラフィックタイプIDを検出し、fme_identity を使用してID属性を作成/更新し、fme_standard_segment / fme_segment_keys を使用して標準セグメントを検査してメンバーキーを追加する。fme_rule_based_segment はターゲティングセグメントのCRUDを提供し、fme_rule_based_segment_definition は有効化/無効化と変更リクエスト承認フローを備えた環境固有のセグメントルールを管理する。

GitOps

リソースタイプ	リスト	取得	作成	更新	削除	実行アクション
`gitops_agent`	x	x
`gitops_argo_project`	x
`gitops_app_project_mapping`	x		x	x	x	`import`
`gitops_autocreate_log`	x
`gitops_application`	x	x				`sync`
`gitops_cluster`	x	x
`gitops_repository`	x	x
`gitops_applicationset`	x	x
`gitops_repo_credential`	x	x
`gitops_app_event`	x
`gitops_pod_log`		x
`gitops_managed_resource`	x
`gitops_resource_action`	x
`gitops_dashboard`		x
`gitops_app_resource_tree`		x
`gitops_cluster_link`	x		x		x

Chaos Engineering

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`chaos_experiment`	x	x	x		x	`run`, `stop`
`chaos_experiment_run`		x
`chaos_experiment_variable`	x
`chaos_component_variable`		x
`chaos_input_set`	x	x	x	x	x
`chaos_experiment_template`	x	x			x	`create_from_template`, `list_revisions`, `get_variables`, `get_yaml`, `compare_revisions`
`chaos_probe`	x	x	x		x	`enable`, `verify`, `get_manifest`
`chaos_probe_in_run`	x
`chaos_probe_template`	x	x			x	`get_variables`
`chaos_infrastructure`	x
`chaos_k8s_infrastructure`	x	x	x			`check_health`
`chaos_enabled_infrastructure`	x
`chaos_environment`	x
`chaos_hub`	x	x	x	x	x
`chaos_hub_fault`	x
`chaos_fault`	x	x			x	`get_variables`, `get_yaml`
`chaos_fault_template`	x	x			x	`list_revisions`, `get_variables`, `get_yaml`, `compare_revisions`
`chaos_fault_experiment_run`	x
`chaos_action`	x	x	x		x	`get_manifest`
`chaos_action_template`	x	x			x	`list_revisions`, `get_variables`, `compare_revisions`
`chaos_loadtest`	x	x	x	x	x	`run`, `stop`
`chaos_service`	x	x	x	x	x	`list_experiment_runs`, `list_load_tests`
`chaos_application_map`	x	x
`discovered_agent`	x
`discovered_namespace`	x
`discovered_service`	x
`discovered_network_map`	x
`chaos_guard_condition`	x	x			x
`chaos_guard_rule`	x	x			x	`enable`
`chaos_recommendation`	x	x
`chaos_risk`	x	x
`chaos_dr_test`	x		x
`scanned_risk`	x	x				`occurrences`, `summary_by_service`
`chaos_risk_rule`	x	x
`chaos_risk_scan`	x	x	x	x	x	`retry`, `abort`, `report`, `report_download`, `heatmap`

クラウドコスト管理（CCM）

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`cost_perspective`	x	x	x	x	x
`cost_breakdown`	x
`cost_timeseries`	x
`cost_summary`	x	x
`cost_recommendation`	x	x				`update_state`, `override_savings`, `create_jira_ticket`, `create_snow_ticket`
`cost_anomaly`	x
`cost_anomaly_summary`		x
`cost_category`	x	x
`cost_account_overview`		x
`cost_filter_value`	x
`cost_recommendation_stats`		x
`cost_recommendation_detail`		x
`cost_commitment`		x
`ai_budget`	x	x	x	x	x
`ai_budget_overview`		x
`ai_budget_consumption`	x
`ai_budget_override_request`	x	x	x			`approve`, `reject`

ソフトウェアエンジニアリングインサイト（SEI）

SEIリソースはトークン効率化のために統合されています。DORA、チーム/組織ツリーの詳細、AIインサイトにはmetricまたはaspectパラメータを使用してください。

リソースタイプ	一覧	取得	アクション実行
`sei_metric`	x
`sei_productivity_metric`		x
`sei_dora_metric`		x	`metric`を渡す: deployment_frequency、change_failure_rate、mttr、lead_time、または *_drilldown
`sei_team`	x	x
`sei_team_detail`	x		`aspect`を渡す: integrations、developers、integration_filters
`sei_org_tree`	x	x
`sei_org_tree_detail`	x	x	`aspect`を渡す: efficiency_profile、productivity_profile、business_alignment_profile、integrations、teams
`sei_business_alignment`	x	x	取得には`aspect`を渡す: feature_metrics、feature_summary、drilldown
`sei_ai_usage`	x	x	`aspect`を渡す: metrics、breakdown、summary、top_languages
`sei_ai_adoption`	x	x	`aspect`を渡す: metrics、breakdown、summary
`sei_ai_impact`		x	`aspect`を渡す: pr_velocity、rework
`sei_ai_raw_metric`	x

ソフトウェアサプライチェーン保証（SCS）

リソースタイプ	一覧	取得
`scs_artifact_source`	x
`artifact_security`	x	x
`scs_artifact_component`	x
`scs_artifact_remediation`		x
`scs_chain_of_custody`		x
`scs_compliance_result`	x
`code_repo_security`	x	x
`scs_sbom`		x

エビデンスボールト

エビデンスボールトは、in-toto アテステーション（SDLC エビデンス）を保存します。一覧は、resource_scope を介してアカウント/組織/プロジェクトのスコープをサポートします。単一のフリーテキストフィルター（パイプライン、アーティファクト単独、gitoid）は search_term を使用します。追加の名前制約は filters.subject_name を使用します。サブジェクトコンテンツダイジェストは filters.subject_digest を使用します。取得は gitoid_sha256 で検索し、org_id/project_id（一覧の行から）が必要です。ダウンロード（harness_execute アクション download）は、時間制限付きの download_url を返します — そのリンクは常にユーザーに表示してください。フィーチャーフラグ SCS_EVIDENCE_VAULT が必要です。

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`attestation`	x	x				`download`

セキュリティテストオーケストレーション（STO）

リソースタイプ	一覧	作成	アクション実行
`security_issue`	x
`security_issue_filter`	x
`security_exemption`	x	x	`approve`, `reject`
`remediation_diff`	x

security_exemption の作成は high_write 操作です。サーバーは認証済み PAT から requester_id を導出し、exemptFutureOccurrences=true を設定し、duration_days が指定されていない場合は 30 にデフォルト設定します。免除の一覧表示では、小さな明示的なページサイズ（例：filters: { "status": "Pending", "size": 5 }）を渡し、各レスポンスで返される _nextPageHint に従ってください。

セキュリティ免除の実行ワークフロー：

harness_list を resource_type="security_exemption" と明示的な status（例：Pending、Approved、Rejected、Expired、または Canceled）とともに使用します。
harness_execute を action="approve" と必須の body.scope（CURRENT、ACCOUNT、ORG、または PROJECT）とともに使用します。CURRENT は免除の既存スコープで承認します。他のスコープは内部で STO プロモートエンドポイントを使用します。サーバーは省略時、認証済みユーザーから body.approver_id を自動入力します。body.comment はオプションです。
action="reject" を使用して免除を拒否します。body.approver_id も省略時は自動入力されます。
個別の promote 実行アクションはありません。要求された結果がアカウント、組織、またはプロジェクトスコープでの承認である場合は、非 CURRENT の body.scope を持つ action="approve" を使用します。

アクセス制御

リソースタイプ	一覧	取得	作成	更新	削除
`user`	x	x
`user_group`	x	x	x	x	x
`service_account`	x	x	x		x
`role`	x	x	x		x
`role_assignment`	x		x
`resource_group`	x	x	x		x
`permission`	x

ガバナンス

リソースタイプ	一覧	取得	作成	更新	削除
`policy`	x	x	x	x	x
`policy_set`	x	x	x	x	x
`policy_evaluation`	x	x

デプロイメントフリーズ

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`freeze_window`	x	x	x	x	x	`toggle_status`
`global_freeze`		x				`manage`

サービスオーバーライド

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`service_override`	x	x	x	x	x

設定

リソースタイプ	一覧	取得	作成	更新	削除	アクション実行
`setting`	x

MCP プロンプト

DevOps

Prompt	Description	Parameters
`build-deploy-app`	エンドツーエンドのCI/CDワークフロー：gitリポジトリをスキャンし、CIパイプライン（Dockerイメージのビルド＆プッシュ）を生成し、K8sマニフェストを検出または生成し、CDパイプラインを作成してデプロイします。CI障害時は自動リトライ（最大5回）、CD障害時はユーザー許可付きで自動リトライ（最大3回）を行います。リトライを使い果たした場合は、手動調査用に作成されたすべてのリソースへのHarness UIディープリンクを提供します。	`repoUrl` (必須), `imageName` (必須), `projectId` (任意), `namespace` (任意)
`debug-pipeline-failure`	失敗した実行を分析します：実行ID、パイプラインID、またはHarness URLを受け付けます。`harness_diagnose` を介してステージ/ステップの内訳、失敗の詳細、デリゲート情報、失敗したステップのログを取得し、根本原因分析と推奨修正を提供します。連鎖するパイプラインの失敗を自動的に追跡します。	`executionId` (任意), `projectId` (任意)
`pipeline_summarizer`	パイプライン実行からすべてのステップログを取得して要約します。`harness_diagnose` と `include_logs: true, include_all_step_logs: true` を使用して各ステップのログを取得し、ステップ名、ステータス、所要時間、発生内容（ログベースの要約）の表を提示します。ステップをスキップしません。	`executionId` (任意), `projectId` (任意)
`create-pipeline`	自然言語の要件から新しいパイプラインYAMLを生成し、コンテキストのために既存のリソースを確認します	`description` (必須), `projectId` (任意)
`create-agent`	Harness AIエージェントを対話的に構築します — 既存のエージェントを確認し（更新時に現在の `agent.uses` とレガシーの `agent.step.group.steps` 仕様形式を検出）、要件を収集し、適切な形式でエージェント仕様を生成し、ユーザーと確認してから、`harness_create`/`harness_update` を介して作成または更新します	`agent_name` (必須), `task_description` (必須), `org_id` (任意), `project_id` (任意)
`onboard-service`	環境とデプロイパイプラインを備えた新しいサービスのオンボーディングを順を追って説明します	`serviceName` (必須), `projectId` (任意)
`dora-metrics-review`	DORAメトリクス（デプロイ頻度、変更失敗率、MTTR、リードタイム）をElite/High/Medium/Lowの分類と改善推奨事項付きでレビューします	`teamRefId` (任意), `dateStart` (任意), `dateEnd` (任意)
`setup-gitops-application`	GitOpsアプリケーションのオンボーディングをガイドします — エージェント、クラスター、リポジトリを検証し、アプリケーションを作成します	`agentId` (必須), `projectId` (任意)
`chaos-resilience-test`	フォールトインジェクション、プローブ、期待される結果を用いてサービス回復力をテストするカオス実験を設計します	`serviceName` (必須), `projectId` (任意)
`feature-flag-rollout`	セーフティゲート付きで環境全体に段階的なフィーチャーフラグのロールアウトを計画および実行します	`flagIdentifier` (必須), `projectId` (任意)
`migrate-pipeline-to-template`	既存のパイプラインを分析し、そこから再利用可能なステージ/ステップテンプレートを抽出します	`pipelineId` (必須), `projectId` (任意)
`delegate-health-check`	デリゲートの接続性、健全性、トークンステータスを確認し、インフラストラクチャの問題をトラブルシューティングします	`projectId` (任意)
`developer-portal-scorecard`	サービス向けのIDPスコアカードをレビューし、開発者エクスペリエンスを向上させるためのギャップを特定します	`projectId` (任意)
`pending-approvals`	承認待ちのパイプライン実行を検索し、詳細を表示して、承認または拒否を提案します	`projectId` (任意), `orgId` (任意), `pipelineId` (任意)

FinOps

Prompt	Description	Parameters
`optimize-costs`	クラウドコストデータを分析し、潜在的な節約額で優先順位付けされた推奨事項と異常を表面化します	`projectId` (任意)
`cloud-cost-breakdown`	サービス、環境、またはクラスター別のクラウドコストをトレンド分析と異常検出付きで深掘りします	`perspectiveId` (任意), `projectId` (任意)
`commitment-utilization-review`	リザーブドインスタンスとセービングプランの利用状況を分析して無駄を見つけ、コミットメントを最適化します	`projectId` (任意)
`cost-anomaly-investigation`	コスト異常を調査します — 根本原因、影響を受けるリソース、および是正措置を特定します	`projectId` (任意)
`rightsizing-recommendations`	ライトサイジングの推奨事項をレビューして優先順位付けし、必要に応じてJiraまたはServiceNowチケットを作成します	`projectId` (任意), `minSavings` (任意)

DevSecOps

Prompt	Description	Parameters
`security-review`	Harnessリソース全体のセキュリティ問題をレビューし、重大度別に是正措置を提案します	`projectId` (任意), `severity` (任意, デフォルト: `critical,high`)
`vulnerability-triage`	パイプラインとアーティファクト全体のセキュリティ脆弱性をトリアージし、重大度と悪用可能性で優先順位付けします	`projectId` (任意), `severity` (任意)
`sbom-compliance-check`	アーティファクトのSBOMとコンプライアンス体制を監査します — ライセンスリスク、ポリシー違反、コンポーネントの脆弱性	`artifactId` (任意), `projectId` (任意)
`supply-chain-audit`	エンドツーエンドのソフトウェアサプライチェーンセキュリティ監査 — 来歴、保管チェーン、ポリシーコンプライアンス	`projectId` (任意)
`security-exemption-review`	保留中のセキュリティ免除をレビューし、一括承認または拒否の決定を行います	`projectId` (任意)
`bulk-exemption-create`	明示的なスコープと期間のガイダンス付きで、複数のSTO問題に対する正当なセキュリティ免除を作成します	`projectId` (必須), `exemption_type` (必須), `reason` (必須), 問題フィルター (任意)
`access-control-audit`	ユーザー権限、過剰権限アカウント、ロール割り当てを監査して、最小権限を強制します	`projectId` (任意), `orgId` (任意)

Harness Code

Prompt	説明	パラメータ
`code-review`	プルリクエストをレビュー — diff、コミット、チェック、コメントを分析し、バグ、セキュリティ、パフォーマンス、スタイルに関する構造化されたフィードバックを提供します	`repoId` (必須), `prNumber` (必須), `projectId` (オプション)
`pr-summary`	ブランチのコミット履歴とdiffからPRタイトルと説明を自動生成します	`repoId` (必須), `sourceBranch` (必須), `targetBranch` (オプション、デフォルト: main), `projectId` (オプション)
`branch-cleanup`	リポジトリ内のブランチを分析し、削除すべき古いブランチやマージ済みブランチを推奨します	`repoId` (必須), `projectId` (オプション)

MCPリソース

リソースURI	説明	MIMEタイプ
`pipeline:///{pipelineId}`	パイプラインYAML定義	`application/x-yaml`
`pipeline:///{orgId}/{projectId}/{pipelineId}`	パイプラインYAML（明示的なスコープ付き）	`application/x-yaml`
`executions:///recent`	直近10件のパイプライン実行サマリー	`application/json`
`schema:///pipeline`	HarnessパイプラインJSONスキーマ	`application/schema+json`
`schema:///template`	HarnessテンプレートJSONスキーマ	`application/schema+json`
`schema:///trigger`	HarnessトリガーJSONスキーマ	`application/schema+json`
`schema:///pipeline_v1` (アルファ)	Harness V1パイプラインJSONスキーマ（簡略化されたステージ/ステップ形式）	`application/schema+json`
`schema:///agent-pipeline`	Harness AIエージェントパイプラインJSONスキーマ	`application/schema+json`
`agent-docs:///legacy-format`	レガシーエージェント仕様形式のリファレンス（`agent.step.group.steps` / `PLUGIN_TASK`）。既存のレガシー形式エージェントを更新する際に`create-agent`プロンプトが読み取ります	`text/markdown`

ツールセットのフィルタリング

デフォルトでは、45のツールセットのうち41が有効です。4つのツールセットはオプトインであり、デフォルトから除外されています：

ansible — Harness Ansible（インベントリ、プレイブック、ホスト、アクティビティ）。プロジェクトスコープであり、多くのユーザーが不要とする概念を追加するためオプトインです。
autonomous_work — Development Harness（自律的な作業）。オプトイン。スコープについてはツールセットの説明を参照してください。
observability-evaluations — スケジュールされた本番テレメトリ評価ルール。デプロイされたスコアリングコントロールプレーンに依存するためオプトインです。
registries-v3 — Harness Artifact Registry v3（パッケージ、バージョン、ファイル、メタデータ、スキャン、ファイアウォール例外）。v3の書き込みが実装されるまでオプトインであり、エージェントがv1レジストリ/アーティファクトとv3パッケージ/バージョンを区別する必要がないようにします。

`+`プレフィックスでツールセットを追加

+プレフィックスを使用して、すべてのデフォルトとともにオプトインツールセットを明示的に含めます：

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

デフォルトツールセットの削除

-プレフィックスを使用して、不要なツールセットを除外します：

# Remove chaos and ccm from defaults
HARNESS_TOOLSETS=-chaos,-ccm

+と-の組み合わせ

# Add Ansible, remove chaos
HARNESS_TOOLSETS=+ansible,-chaos

明示的な許可リスト

明示的なカンマ区切りリスト（プレフィックスなし）はデフォルトを完全に置き換えます。リストされたツールセットのみが有効になります：

# Only expose pipelines, services, and connectors
HARNESS_TOOLSETS=pipelines,services,connectors

利用可能なツールセット名：

| ツールセット | リソースタイプ | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `platform` | organization, project | | `pipelines` | pipeline, pipeline_v1, pipeline_dynamic_execution, execution, execution_inputs, trigger, pipeline_summary, input_set, approval_instance | | `agents` | agent, agent_run | | `services` | service | | `environments` | environment | | `connectors` | connector, connector_catalogue | | `infrastructure` | infrastructure | | `secrets` | secret | | `logs` | execution_log | | `audit` | audit_event | | `delegates` | delegate, delegate_token | | `repositories` | repository, branch, commit, file_content, tag, repo_rule, space_rule | | `registries` | registry, artifact, artifact_version, artifact_file | | `file_store` | file_store | | `templates` | template | | `dashboards` | dashboard, dashboard_data | | `idp` | idp_entity, scorecard, scorecard_check, scorecard_stats, scorecard_check_stats, idp_score, idp_workflow, idp_tech_doc | | `pull-requests` | pull_request, pr_reviewer, pr_comment, pr_check, pr_activity | | `feature-flags` | fme_workspace, fme_environment, fme_feature_flag, fme_feature_flag_definition, fme_rollout_status, fme_rule_based_segment, fme_rule_based_segment_definition, fme_traffic_type, fme_identity, fme_standard_segment, fme_segment_keys, fme_segment, fme_segment_definition, fme_metric, fme_event_type | | `gitops` | gitops_agent, gitops_argo_project, gitops_app_project_mapping, gitops_autocreate_log, gitops_application, gitops_cluster, gitops_repository, gitops_applicationset, gitops_repo_credential, gitops_app_event, gitops_pod_log, gitops_managed_resource, gitops_resource_action, gitops_dashboard, gitops_app_resource_tree, gitops_cluster_link | | `chaos` | chaos_experiment, chaos_experiment_run, chaos_experiment_variable, chaos_component_variable, chaos_input_set, chaos_experiment_template, chaos_probe, chaos_probe_in_run, chaos_probe_template, chaos_infrastructure, chaos_k8s_infrastructure, chaos_enabled_infrastructure, chaos_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan | | `ccm` | cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment | | `sei` | sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric | | `scs` | scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom | | `evidence-vault` | attestation | | `sto` | security_issue, security_issue_filter, security_exemption, remediation_diff | | `dbops` | database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline | | `autonomous_work` *(オプトイン)* | work_item, work_item_resume, work_item_approve, work_timeline, work_budget, work_phase, work_phase_artifact, work_artifact, budget, budget_grant, budget_usage, work_class, work_trigger, capability, risk_evaluator, team, member, member_template, software_component, content_source_connector | | `access_control` | user, user_group, service_account, role, role_assignment, resource_group, permission | | `governance` | policy, policy_set, policy_evaluation | | `freeze` | freeze_window, global_freeze | | `overrides` | service_override | | `settings` | setting | | `knowledge-graph` | kg_queryable_type_summary, kg_grammar, hql_query | | `semantic-layer` | kg_type, kg_related_type | | `ai-evals` | eval_dataset, eval_dataset_item, evaluation, eval_run, eval_run_item, eval_run_by_eval, eval_metric, eval_metric_set, eval_metric_set_entry, eval_suite, eval_suite_evaluation, eval_suite_run, eval_target, eval_annotation, eval_analytics, eval_git_settings, eval_registry_item, eval_git_registration, online_eval | | `observability-evaluations` *(オプトイン)* | observability_evaluation_rule | | `iacm` | iacm_workspace, iacm_variable_set, iacm_resource, iacm_module, iacm_provider, iacm_workspace_costs, iacm_activity_resource_change | | `ansible` *(オプトイン)* | ansible_inventory, ansible_playbook, ansible_host, ansible_host_activity, ansible_activity | | `registries-v3` *(オプトイン)* | package_v3, version_v3, file_v3, registry_metadata_v3, package_metadata_v3, version_metadata_v3, file_metadata_v3, metadata_key_v3, metadata_value_v3, artifact_scan_v3, bulk_scan_evaluation_v3, firewall_exception_v3, firewall_exception_version_v3 | | `release-management` | release_process, release_activity, release, release_execution_phase, release_execution_task, release_execution_activity, release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_input, release_execution_activity_output | | `vibe` | vibe_project, vibe_app_lifecycle | ## アーキテクチャ

                 +------------------+
                 |   AI Agent       |
                 |  (Claude, etc.)  |
                 +--------+---------+
                          |  MCP (stdio or HTTP)
                 +--------v---------+
                |    MCP Server     |
                | 11 Generic Tools  |
                 +--------+---------+
                          |
                 +--------v---------+
                |    Registry       |  <-- Declarative resource definitions
                | 45 Toolsets (41 default) |
                |  255 Resource Types|
                 +--------+---------+
                          |
                 +--------v---------+
                 |  HarnessClient    |  <-- Auth, retry, rate limiting
                 +--------+---------+
                          |  HTTPS
                 +--------v---------+
                 |  Harness REST API |
                 +-------------------+

仕組み

ツールは汎用的な動詞です: harness_list、harness_get など。これらは resource_type パラメータを受け取り、適切なAPIエンドポイントにルーティングします。
レジストリは各 resource_type を ResourceDefinition にマッピングします。これはHTTPメソッド、URLパス、パス/クエリパラメータのマッピング、レスポンス抽出ロジックを指定する宣言型データ構造です。
ディスパッチはリソース定義を解決し、HTTPリクエストを構築し（パス置換、クエリパラメータ、resource_scope 対応のアカウント/組織/プロジェクト注入）、HarnessClient を通じてHarness APIを呼び出し、関連するレスポンスデータを抽出します。
ツールセットフィルタリング（HARNESS_TOOLSETS）は、起動時にレジストリに読み込まれるリソース定義を制御します。
構造化出力はMCP outputSchema で宣言されます。harness_list は配列と一般的なリストラッパーをオブジェクト形状の structuredContent に強制変換し、厳格なクライアントに対応します。
ディープリンクはレスポンスに自動的に追加され、すべてのリソースに対してHarness UIの直接URLを提供します。
コンパクトモードはリスト結果から冗長なメタデータを削除し、実用的なフィールド（ID、ステータス、タイプ、タイムスタンプ、ディープリンク）のみを保持してトークン使用量を最小限に抑えます。

新しいリソースタイプの追加

src/registry/toolsets/ に新しいファイルを作成するか、既存のツールセットにリソースを追加します:

// src/registry/toolsets/my-module.ts
import type { ToolsetDefinition } from "../types.js";

export const myModuleToolset: ToolsetDefinition = {
  name: "my-module",
  displayName: "My Module",
  description: "Description of the module",
  resources: [
    {
      resourceType: "my_resource",
      displayName: "My Resource",
      description: "What this resource represents",
      toolset: "my-module",
      scope: "project",                    // "project" | "org" | "account"
      identifierFields: ["resource_id"],
      listFilterFields: ["search_term"],
      operations: {
        list: {
          method: "GET",
          path: "/my-module/api/resources",
          queryParams: { search_term: "search", page: "page", size: "size" },
          responseExtractor: (raw) => raw,
          description: "List resources",
        },
        get: {
          method: "GET",
          path: "/my-module/api/resources/{resourceId}",
          pathParams: { resource_id: "resourceId" },
          responseExtractor: (raw) => raw,
          description: "Get resource details",
        },
      },
    },
  ],
};

次に、src/registry/index.ts でインポートし、ALL_TOOLSETS 配列に追加します。ツールファイルの変更は不要です。

開発

# Build
pnpm build

# Watch mode
pnpm dev

# Type check
pnpm typecheck

# Run tests
pnpm test

# Watch tests
pnpm test:watch

# Interactive MCP Inspector
pnpm inspect

# Refresh generated README counts from the built registry
pnpm docs:generate

# Verify README counts and clone instructions are current
pnpm docs:check

# Sync and verify JSON Schemas used by harness_schema
pnpm sync-schemas
pnpm check-schema-coverage

プロジェクト構造

src/
  index.ts                          # Entrypoint, transport setup
  config.ts                         # Env var validation (Zod)
  client/
    harness-client.ts               # HTTP client (auth, retry, rate limiting)
    types.ts                        # Shared API types
  registry/
    index.ts                        # Registry class + dispatch logic
    types.ts                        # ResourceDefinition, ToolsetDefinition, etc.
    toolsets/                        # One file per toolset (declarative data)
      platform.ts
      pipelines.ts
      services.ts
      ccm.ts
      access-control.ts
      ...
  tools/                            # 11 generic MCP tools
    harness-list.ts
    harness-get.ts
    harness-create.ts
    harness-update.ts
    harness-delete.ts
    harness-execute.ts
    harness-search.ts
    harness-diagnose.ts
    harness-describe.ts
    harness-status.ts
    harness-schema.ts

  resources/                        # MCP resource providers
    pipeline-yaml.ts
    execution-summary.ts
  prompts/                          # MCP prompt templates
    build-deploy-app.ts             # DevOps: end-to-end build & deploy workflow
    debug-pipeline.ts               # DevOps: debug failed executions
    create-pipeline.ts              # DevOps: generate pipeline from requirements
    onboard-service.ts              # DevOps: onboard new service
    dora-metrics.ts                 # DevOps: DORA metrics review
    setup-gitops.ts                 # DevOps: GitOps application setup
    chaos-resilience.ts             # DevOps: chaos experiment design
    feature-flag-rollout.ts         # DevOps: progressive flag rollout
    migrate-to-template.ts          # DevOps: extract templates from pipeline
    delegate-health.ts              # DevOps: delegate health check
    developer-scorecard.ts          # DevOps: IDP scorecard review
    optimize-costs.ts               # FinOps: cost optimization
    cloud-cost-breakdown.ts         # FinOps: cost deep-dive
    commitment-utilization.ts       # FinOps: RI/savings plan analysis
    cost-anomaly.ts                 # FinOps: anomaly investigation
    rightsizing.ts                  # FinOps: rightsizing recommendations
    security-review.ts              # DevSecOps: security issue review
    vulnerability-triage.ts         # DevSecOps: vulnerability triage
    sbom-compliance.ts              # DevSecOps: SBOM compliance audit
    supply-chain-audit.ts           # DevSecOps: supply chain audit
    exemption-review.ts             # DevSecOps: exemption approval
    access-control-audit.ts         # DevSecOps: access control audit
    code-review.ts                  # Harness Code: PR code review
    pr-summary.ts                   # Harness Code: auto-generate PR summary
    branch-cleanup.ts               # Harness Code: stale branch cleanup
    pending-approvals.ts            # Approvals: find and act on pending approvals
  utils/
    cli.ts                          # CLI arg parsing (transport, port)
    errors.ts                       # Error normalization
    logger.ts                       # stderr-only logger
    progress.ts                     # MCP progress & logging notifications
    rate-limiter.ts                 # Client-side rate limiting
    deep-links.ts                   # Harness UI deep link builder
    response-formatter.ts           # Consistent MCP response formatting
    compact.ts                      # Compact list output for token efficiency
tests/
  config.test.ts                    # Config schema validation tests
  utils/
    response-formatter.test.ts
    deep-links.test.ts
    errors.test.ts
  registry/
    registry.test.ts                # Registry loading, filtering, dispatch tests

エリシテーション

書き込みツール（harness_create、harness_update、harness_delete、harness_execute）は、アクションのリスクが必要とする場合にMCPエリシテーションを使用してユーザーに確認を求めます — medium_write、high_write、destructive 操作のみです。低リスクの作成/更新/読み取り（例: pipeline.create、pipeline.update、hql_query.run）はプロンプトなしで静かに実行されます。プロンプトが表示されると、ユーザーは何が起ころうとしているかを確認し、受け入れるか拒否します。これにより、実際に変更や実行を行う操作に対して、人間がループ内で承認を行うことができます。

仕組み:

LLMが medium_write+ リスクの書き込みツールを呼び出します（例: harness_delete、harness_execute pipeline.run）。低リスクの作成/更新/読み取りはプロンプトを表示しません。
サーバーは操作の概要と confirm チェックボックス（デフォルトでチェック済み）を含むエリシテーションリクエストをクライアントに送信します。
ユーザーは詳細を確認し、承認（confirm がチェックされた状態）または拒否/キャンセルをクリックします。
confirm: true がチェックされた状態で承認された場合、操作は続行されます。confirm がチェックされていない状態で承認された場合、拒否された場合、またはキャンセルされた場合はブロックされ、LLMに通知されます（明示的な拒否は権威的であり、ツール呼び出しの confirm: true によってバイパスされません）。

クライアントサポート:

クライアント	エリシテーションサポート
Cursor	あり
VS Code (Copilot)	あり
Claude Desktop	未対応
Devin Desktop	未対応
MCP Inspector	あり

クライアントサポートがない場合、エリシテーション動作は操作リスクによって異なります:

リスクレベル	クライアントがエリシテーションをサポート	`confirm: true` が渡される	動作
`read`、`low_write`	任意	任意	静かに続行 — プロンプトは表示されません（`confirm` はこのリスク層では効果がありません）
`medium_write`、`high_write`、`destructive`	あり	任意	ユーザーにプロンプトを表示。ユーザーが `confirm: true`（スキーマのデフォルト）付きで承認した場合のみ続行。明示的な拒否、キャンセル、または `confirm: false` 付きの承認（ユーザーがチェックボックスをオフにした）は権威的であり、ツール呼び出しの `confirm: true` によってバイパスされません。`confirm` フィールドが欠落した承認は、クライアントが使用可能なプロンプトを表示できなかったものとして扱われます — `confirm: true` で再試行することで回復可能です
`medium_write`、`high_write`、`destructive`	なし	なし	ブロック（`confirm: true` で再試行するヒント付きエラーを返す）
`medium_write`、`high_write`、`destructive`	なし	あり	続行（非対話型自動化の明示的なオプトイン）
任意（`HARNESS_AUTO_APPROVE_RISK` 以下）	任意	任意	プロンプトなしで自動承認

elicitInput が実行時に失敗した場合（トランスポートエラー、サポートされていないメソッド）、medium_write+ 操作では、呼び出し元が confirm: true を渡さない限り呼び出しはブロックされます。confirm: true は、クライアントがプロンプトを表示できなかった場合や退化した承認（{action: "accept"} で確認フィールドなし）を返した場合のフォールバックとして尊重されますが、エリシテーションハンドシェイクを完了したクライアントからの明示的な拒否/キャンセルを上書きしません。

自律モード

自律モードとは、サーバーが確認プロンプトなしですべての操作（書き込みや破壊的なアクションを含む）を続行することを意味します。設定するには:

HARNESS_AUTO_APPROVE_RISK=all

これはデプロイメントレベルの上限です。一度設定すると、個々のセッションはそれを超えてエスカレーションできません（ただし、x-harness-auto-approve-risk ヘッダーを介してセッションごとにより厳格なしきい値を選択することはできます）。

またはMCPクライアント設定で:

{
  "mcpServers": {
    "harness": {
      "command": "npx",
      "args": ["harness-mcp-v2"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "HARNESS_AUTO_APPROVE_RISK": "all"
      }
    }
  }
}

部分的自律性: 特定のリスクレベルまでのみ自動承認し、より高リスクの操作ではプロンプトを表示することもできます:

# Auto-approve reads and low-risk writes; prompt for medium_write, high_write, destructive
HARNESS_AUTO_APPROVE_RISK=low_write

# Auto-approve up to high-risk writes; only prompt for destructive operations
HARNESS_AUTO_APPROVE_RISK=high_write

値	自動承認されるもの
`none`（デフォルト）	なし — 自動承認しきい値なし
`low_write`	読み取り + 低リスク書き込み
`medium_write`	読み取り + 低 + 中リスク書き込み
`high_write`	読み取り + 低 + 中 + 高リスク書き込み
`all`	破壊的操作を含むすべて

自律モードの警告: HARNESS_AUTO_APPROVE_RISK=all はすべての操作（harness_delete を含む）の確認をスキップします。注意して使用し、HARNESS_TOOLSETS と組み合わせて利用可能なリソースタイプを制限することを検討してください。

移行に関する注意: HARNESS_SKIP_ELICITATION=true は引き続きサポートされ、HARNESS_AUTO_APPROVE_RISK=all にマッピングされます。非推奨警告がstderrに記録されます。両方が設定されている場合、HARNESS_AUTO_APPROVE_RISK が優先されます。

安全性

シークレットは決して公開されません。 secret リソースタイプはメタデータのみを返します（名前、タイプ、スコープ）— シークレット値はどのレスポンスにも含まれません。
確認が必要な操作は、利用可能な場合エリシテーションを使用します。 書き込みまたは実行アクションに medium_write、high_write、または destructive のリスクがある場合、harness_create、harness_update、harness_delete、harness_execute は続行前にMCPエリシテーションを試みます（エリシテーションを参照）。低リスクアクション（read、low_write — 例: pipeline.create、pipeline.update、hql_query.run）はプロンプトなしで静かに実行されます。
中リスク以上はフェイルクローズします。 medium_write、high_write、または destructive 操作で確認が得られない場合、盲目的に実行する代わりにブロックされます。自律ワークフローでは HARNESS_AUTO_APPROVE_RISK で上書きします。
CORSは同一オリジンに制限されます。 HTTPトランスポートは同一オリジンリクエストのみを許可し、localhost上のMCPサーバーを標的とする悪意のあるWebサイトからのCSRF攻撃を防ぎます。
HTTPレート制限。 HTTPトランスポートはIPごとに毎分60リクエストを強制し、リクエストフラッディングを防ぎます。
APIレート制限。 Harness APIクライアントは毎秒10リクエストの制限を強制し、上流のレート制限に達するのを防ぎます。
ページネーション境界が強制されます。 リストクエリは合計10,000アイテム、ページあたり100アイテムに制限され、メモリ枯渇を防ぎます。
バックオフ付きリトライ。 一時的な障害（HTTP 429、5xx）は指数バックオフとジッターで再試行されます。
localhostバインド。 HTTPトランスポートはデフォルトで 127.0.0.1 にバインドされます — ネットワークからはアクセスできません。
stdoutログなし。 すべてのログはstderrに送られ、stdio JSON-RPCトランスポートの破損を防ぎます。

補完スキル

Harness MCPサーバーは**Harness Skills**と組み合わせると効果的です — 一般的なHarnessワークフロー向けに設計された既製のClaude Codeスキル（スラッシュコマンド）のコレクションです。このMCPサーバーと一緒にインストールすると、カスタムプロンプトを書かずに /deploy、/rollback、/triage などの高レベルな自動化を利用できます。

トラブルシューティングと一般的な落とし穴

症状	考えられる原因	対処方法
`HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...`	APIキーがサポートされているアカウントスコープ形式（`pat.<accountId>...` または `sat.<accountId>...`）ではないため、アカウントIDを推測できない	`HARNESS_ACCOUNT_ID` を明示的に設定する
起動時の `Unknown transport: "..."`	サポートされていないCLIトランスポート引数	`stdio` または `http` のみを使用する
起動時の `Invalid HARNESS_TOOLSETS: ...`	1つ以上のツールセット名が認識されない	Toolset Filtering の名前のみを使用する（完全一致）
HTTP `mcp-session-id header is required...`	セッションヘッダーなしでセッションリクエストが送信された	最初に `initialize` を送信し、`POST/GET/DELETE /mcp` に `mcp-session-id` を含める
HTTP `Session not found...`	`MCP_SESSION_TTL_MS` ミリ秒のアイドル時間後にセッションが期限切れになった、またはすでに閉じられた	`initialize` を再実行して新しいセッションを作成し、新しいヘッダーで再試行する
`/mcp` での HTTP `405 Method Not Allowed`	MCPエンドポイントでサポートされていないメソッド	`POST`、`GET`、`DELETE`、または `OPTIONS` のみを使用する
HTTP `Invalid request`	無効なJSONボディ、またはリクエストボディが `HARNESS_MAX_BODY_SIZE_MB` を超えている	JSONペイロードのサイズ/形状を検証する; 必要に応じて `HARNESS_MAX_BODY_SIZE_MB` を増やす
ツールからの `Unknown resource_type "..."`	リソースタイプのスペルミス、または `HARNESS_TOOLSETS` でフィルタリングされている	`harness_describe` を呼び出して（オプションで `search_term` を使用）有効なタイプを確認する
`Missing required field "... for path parameter ..."`	プロジェクト/組織スコープの呼び出しに識別子が不足している	`HARNESS_ORG`/`HARNESS_PROJECT` を設定するか、ツール呼び出しごとに `org_id`/`project_id` を渡す
`resource_scope "org" requires org_id...` または `resource_scope "project" requires project_id...`	マルチスコープリソースが、十分な識別子なしで組織/プロジェクトスコープに強制された	不足している `org_id`/`project_id` を渡す、`HARNESS_ORG`/`HARNESS_PROJECT` を設定する、またはサポートされている場合は `resource_scope: "account"` を使用する
`Read-only mode is enabled ... operations are not allowed`	`HARNESS_READ_ONLY=true` が作成/更新/削除/実行をブロックしている	書き込み操作を意図している場合は `HARNESS_READ_ONLY=false` を設定する
パイプライン実行が必須入力の未解決でプリフライト失敗	提供された `inputs` が必須のランタイムプレースホルダーをカバーしていない	`runtime_input_template` を取得し、不足している単純なキーを供給するか、構造的入力に `input_set_ids` を使用する
パイプラインCI省略記法（`branch`、`tag`、`pr_number`、`commit_sha`）が適用されなかった	`inputs.build` がすでに提供されているため、省略記法の展開が意図的にスキップされた	省略記法の展開を使用するには `inputs.build` を削除するか、完全な明示的な `build` 構造を維持する
パイプライン実行が間違ったYAMLリビジョンを読み込んだ	パイプライン定義がGitに保存されており、実行が目的のパイプラインブランチを指定しなかった	`run` アクションで `params.pipeline_branch` を渡す; これはHarness `branch` にマッピングされる
`wait: true` が `_wait.error` を返した	パイプライントリガーは成功したが、サーバー側のポーリングが失敗した	再実行を決定する前に、`harness_get(resource_type="execution", ...)` で `execution_id` を再確認する
`wait: true` が `execution_timed_out: true` を返した	`wait_timeout_seconds` の前に実行が終了ステータスに達しなかった	返された `execution_id` を使用してステータスを再確認する; `harness_diagnose` を実行する前に終了ステータスを待つ
実行ログが空、またはブロブダウンロードが403を返す	HarnessホストのログブロブURLには、特に内部または自己管理ホストの場合、設定されたHarnessクライアント/認証パスが必要	`HARNESS_BASE_URL` をターゲットのHarnessホストに向けたままにし、MCPクライアントをバイパスせずに `harness_get(resource_type="execution_log", ...)` または `harness_diagnose(..., include_logs=true)` を使用する
`Operation declined by user` / `Operation cancelled by user`	ユーザーが確認ダイアログを拒否またはキャンセルした — 権威的	操作の詳細をユーザーと確認する; `confirm: true` は明示的な拒否をバイパスしない。ユーザーがプロンプトを受け入れる必要がある
`Operation blocked: the client could not surface a usable confirmation prompt`	クライアントがエリシテーションサポートを欠いている、`elicitInput` が失敗した、または退化した受け入れを返した	非対話型自動化には `confirm: true` で再試行するか、エリシテーションをサポートするクライアントを使用する
テンプレート作成/更新時の `body.template_yaml (or body.yaml) is required`	テンプレートAPIは完全なYAMLペイロードを期待する	`body` に完全な `template_yaml` 文字列を提供する; 削除の場合、`version_label` を渡して1つのバージョンを削除する（省略すると全バージョンを削除）
起動時の `HARNESS_BASE_URL must use HTTPS`	`HARNESS_BASE_URL` がHTTP URLに設定されている	HTTPSを使用するか、ローカル開発には `HARNESS_ALLOW_HTTP=true` を設定する

ライセンス

MIT

Harness

Harness MCPで何ができますか？

ドキュメント

Harness MCP Server 2.0

このMCPサーバーを使う理由

前提条件

クイックスタート

オプション0：ホステッドHarness MCP

オプション1：npx（推奨）

オプション2：グローバルインストール

オプション3：ソースからビルド

Anthropic MCPディレクトリバンドル

CLI使用法

HTTPトランスポート

HarnessID OAuthモード

マルチユーザーモード

クライアント設定

ホステッドHarness MCP

Claude Desktop（claude_desktop_config.json）

Claude Code（claude mcp add経由）

Cursor（.cursor/mcp.json）

Devin Desktop（~/.windsurf/mcp.json）

MCPゲートウェイ

Docker MCPゲートウェイ

Portkey

LiteLLM

Envoy AI Gateway

Kong

その他のゲートウェイ

Docker

Kubernetes

設定

セマンティック検索

HTTPS の強制

監査ログ

ツールリファレンス

スキーマ検索ワークフロー

ツール例

パイプライン実行ワークフロー（推奨）

動的パイプライン実行

実行入力フォレンジック

パイプライン実行待機モード

パイプラインストレージモード

リソースタイプ

プラットフォーム

パイプライン

AIエージェント

サービス

環境

コネクタ

インフラストラクチャ

シークレット

実行ログ

監査証跡

デリゲート

コードリポジトリ

アーティファクトレジストリ

ファイルストア

テンプレート

ダッシュボード

データベース DevOps

Infrastructure as Code 管理（IaCM）

内部開発者ポータル（IDP）

プルリクエスト

リリース管理

Vibe

フィーチャーフラグ

GitOps

Chaos Engineering

クラウドコスト管理（CCM）

ソフトウェアエンジニアリングインサイト（SEI）

ソフトウェアサプライチェーン保証（SCS）

エビデンスボールト

セキュリティテストオーケストレーション（STO）

アクセス制御

ガバナンス

デプロイメントフリーズ

サービスオーバーライド

設定

MCP プロンプト

Claude Desktop（`claude_desktop_config.json`）

Claude Code（`claude mcp add`経由）

Cursor（`.cursor/mcp.json`）

Devin Desktop（`~/.windsurf/mcp.json`）

`+`プレフィックスでツールセットを追加