Harness

公式

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

GitHub

114

Harness MCPで何ができますか？

Harness リソースを参照 — harness_list を使って、パイプライン、サービス、環境、組織、プロジェクト、またはフィーチャーフラグを一覧表示するようエージェントに依頼します。
リソースを調査 — リソースの種類と識別子を指定して harness_get を使い、特定の Harness リソースの詳細を取得します。
リソースを作成 — harness_create を使って、パイプラインやサービスなどの Harness リソースを作成するようエージェントに依頼します。
複数プロジェクトの検出 — エージェントはアカウント階層を動的にたどるため、「すべてのプロジェクトで失敗した実行を表示して」と依頼できます。
スコープを設定したセッション — 呼び出しごとに繰り返し指定する代わりに、HARNESS_ORG と HARNESS_PROJECT を使って、セッションごとにデフォルトの組織とプロジェクトを設定します。

ドキュメント

Harness MCP Server 2.0

AI エージェントに、11 個の統合ツールと 274 種類のリソースを通じて Harness.io プラットフォームへのフルアクセスを提供する MCP（Model Context Protocol）サーバーです。

この MCP Server を使う理由

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

このサーバーは異なる方式で構築されています。

11 個のツール、274 種類のリソース。 レジストリベースのディスパッチシステムにより、harness_list、harness_get、harness_create などを、パイプライン、サービス、環境、組織、プロジェクト、機能フラグ、コストデータなど、あらゆる Harness リソースにルーティングします。LLM は数百個ではなく、11 個のツールから選択します。
プラットフォーム全体を網羅。 CI/CD、GitOps、Feature Flags、Cloud Cost Management、Security Testing、Chaos Engineering、Database DevOps、Internal Developer Portal、Software Supply Chain、Infrastructure as Code Management、Release Management、Governance、Service Overrides、Knowledge Graph などを網羅する 44 個のデフォルトツールセットを提供します。必要に応じて、Ansible とオブザーバビリティ評価のカバレッジもオプトインで利用できます。
複数プロジェクトのワークフローに標準対応。 エージェントは組織とプロジェクトを動的に検出するため、環境変数をハードコードする必要はありません。「すべてのプロジェクトで失敗した実行を表示して」と尋ねると、エージェントはアカウント階層全体をたどれます。
35 個のプロンプトテンプレート。 アプリのエンドツーエンドのビルドとデプロイ、失敗したパイプラインのデバッグ、DORA メトリクスの確認、脆弱性のトリアージ、クラウドコストの最適化、アクセス制御の監査、機能フラグのロールアウト計画、プルリクエストのレビュー、保留中のパイプラインの承認など、一般的なワークフロー向けの事前構築済みプロンプトを用意しています。
あらゆる環境で動作。 ローカルクライアント（Claude Desktop、Cursor、Devin Desktop）向けの Stdio トランスポート、リモートまたは共有デプロイ向けの HTTP トランスポートに対応し、Docker と Kubernetes にも対応しています。
設定不要ですぐに開始。 Harness API キーを指定するだけです。アカウント ID は PAT および SAT トークンから自動抽出され、組織とプロジェクトのデフォルト設定は任意です。また、ツールセットのフィルタリングにより、必要なものだけを公開できます。
拡張性を考慮した設計。 新しい Harness リソースの追加は、宣言型データファイルを追加するだけです。新しいツール登録、スキーマ変更、プロンプト更新は必要ありません。

前提条件

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

Harness アカウントにログインします
My Profile → API Keys → + New API Key に移動します
API キーの下に新しい Token を作成します。これにより、<prefix>.<accountId>.<tokenId>.<secret> 形式の PAT または SAT が生成されます
トークンを安全な場所に保存します。次の手順で必要になります

詳しい手順については、Harness API Quickstartを参照してください。

クイックスタート

オプション 0: Hosted Harness MCP

Harness アカウントでホスト型 MCP サービスが有効になっている場合、リモート MCP サーバーに対応したクライアントは、サーバーをローカルで実行せずに、管理対象エンドポイントへ直接接続できます。

重要: ホスト型 MCP サービスでは、HARNESS_API_KEY ではなく Harness Platform OAuth を使用します。また、エンドポイントを使用する前に、アカウントごとに Harness Support による有効化と設定が必要です。

設定例については、Hosted 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 Directory バンドル

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 Release に自動的に公開されます。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`	`oauth` モードおよび `oauth-proxy` モードでの RFC 9728 メタデータ
`/.well-known/oauth-protected-resource/mcp`	`GET`	デフォルトの `/mcp` リソース向けのパス対応 RFC 9728 メタデータ
`/.well-known/oauth-authorization-server`	`GET`	`oauth-proxy` モードでの組み込みブローカー RFC 8414 メタデータ
`/oauth/authorize`	`GET`	上流プロバイダーと HarnessID を通じて MCP クライアントのログインを開始
`/oauth/upstream/callback`	`GET`	上流 ID プロバイダーのコールバック
`/oauth/harnessid/callback`	`GET`	HarnessID ログインのコールバック
`/oauth/token`	`POST`	MCP クライアント向けに上流トークンを返すか更新します。HarnessID トークンは返しません

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

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

共有またはリモートからアクセス可能なシングルユーザーおよびマルチユーザーのデプロイでは、HARNESS_MCP_AUTH_TOKEN を設定してください。設定した場合、/mcp へのすべての POST、GET、DELETE リクエストに Authorization: Bearer <token> を含める必要があります。
OAuth モードでは、HARNESS_MCP_AUTH_TOKEN の代わりに HarnessID アクセストークンを受け付けます。また、未認証アクセスを許可するオプトアウト設定なしで、ループバック以外のアドレスにバインドできます。
OAuth プロキシモードでは、上流 ID プロバイダーのトークンを受け付け、内部でユーザーごとの 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 です（デフォルトは 10 MB）。
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

デフォルトでは、issuer は https://id.harness.io/idp/realms/HarnessIDP、resource は https://mcp.harness.io/mcp、OAuth クライアントは mcp-client、Harness API のベース URL は https://mcp.harness.io/cli です。QA、ローカル開発、または別の Harness 環境でのみ、これらを上書きしてください。

このモードでは HARNESS_API_KEY を設定しないでください。HARNESS_MCP_OAUTH_JWKS_URI はデフォルトで <issuer>/protocol/openid-connect/certs となり、アカウント情報はトークンから取得されるため HARNESS_ACCOUNT_ID は不要です。オプトインの appsec ツールセット（HARNESS_TOOLSETS=+appsec）が有効な場合、セッションでは initialize リクエストに x-harness-appsec-api-key も渡す必要があります（HarnessID OAuth トークンが api.traceable.ai に転送されることはありません）。

サーバーは 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を参照してください。

上流 ID プロバイダー OAuth プロキシモード

OAuth プロキシモードには、機密情報を扱う HarnessID クライアントが必要です。このクライアントは Harness ID チームが作成し、クライアント ID とクライアントシークレットを提供します。このモードを有効にする前に、Harness ID チームにお問い合わせください。

MCP クライアントに上流 ID プロバイダーのトークンのみを保持させる場合は、HARNESS_MCP_MODE=oauth-proxy を設定します。公開クライアント名は任意です。HARNESS_MCP_BROKER_CLIENT_ID には、MCP クライアントが使用するものと同じ名前を設定してください。統合 OAuth ブローカーは上流のブラウザーログインを開始し、同じフロー内で HarnessID ログインを完了して、上流のアクセストークンとリフレッシュトークンのみを MCP クライアントに返します。各 /mcp リクエストで、サーバーは上流トークンを検証し、ユーザーごとにキャッシュされた HarnessID アクセストークンを使用します。有効期限が切れる前に、リフレッシュトークンで更新します。上流 ID プロバイダーと HarnessID の対応付けが見つからない場合は 401 を返し、クライアントに再ログインを促します。HarnessID トークンがサーバーの外部に出ることはありません。リフレッシュトークン、キャッシュされたアクセストークン、一時的な OAuth 状態は、保存時に暗号化されます。このモードは HTTP 専用です。また、上流の issuer と audience、および安定した 32 バイトの vault key が必要です。設定とエンドツーエンドの MCP テストコマンドについては、上流 ID プロバイダー 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 ヘッダーを指定して、そのセッションのデフォルトスコープを設定することもできます。
オプトインの appsec ツールセット（HARNESS_TOOLSETS=+appsec）が有効な場合、appsec_* リソースを呼び出すセッションでは、initialize リクエストで x-harness-appsec-api-key も指定する必要があります（セッションの x-harness-api-key が api.traceable.ai に転送されることはありません）。
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 は省略可能です。これらは、ツール呼び出しごとに指定されていない場合に使用する org ID と project ID を設定します。エージェントは harness_list(resource_type="organization") と harness_list(resource_type="project") を使用して、org と project を動的に検出できます。非推奨の名前である HARNESS_DEFAULT_ORG_ID と HARNESS_DEFAULT_PROJECT_ID も、後方互換性のため引き続き受け付けられます。

Hosted Harness MCP

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

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

ホスト型エンドポイント https://mcp.harness.io/mcp はマネージドサービスです。Claude、Cursor、Cowork のクライアント側 MCP 設定では、ルーティング先の Harness 環境を変更できません。Harness0 またはその他のプライベート Harness SaaS 環境で利用するには、Harness Support に連絡してその環境向けに Hosted MCP を有効化／構成するか、ローカル／セルフホストサーバーを実行し、HARNESS_BASE_URL を対象の Harness ホストに設定してください。

Hosted MCP の例:

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

Hosted とローカルの両方のエントリを含む例:

{
  "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 Gateway

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

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

認証情報を一元管理 — エージェント設定に API キーを含める必要がありません
チーム全体のすべてのツール呼び出しに対するガバナンスと監査ログ
N 個の MCP サーバーへの接続の代わりに、エージェント向けの単一エンドポイント
アクセス制御 — チームごとに使用可能なツールを制限

Docker MCP Gateway

Docker MCP Gateway の設定にサーバーを登録します。

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

Portkey

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

{
  "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 が http://localhost:8080/mcp を上流 MCP バックエンドとしてルーティングするように設定します。

Kong

Kong の AI MCP Proxy プラグインを使用して、既存の 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

このデプロイでは、readiness/liveness プローブ、リソース制限、非 root のセキュリティコンテキストを設定して、2 つのレプリカを実行します。Service は内部向けにポート 80 を公開し、コンテナのポート 3000 を宛先とします。

設定

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

変数	必須	デフォルト	説明
`HARNESS_MCP_MODE`	いいえ	`single-user`	デプロイモード: `single-user`、`multi-user`、`oauth`（直接 HarnessID トークンを使用）、または `oauth-proxy`（ユーザーごとの HarnessID トークンと交換する上流 ID プロバイダートークン）
`HARNESS_API_KEY`	はい*	--	Harness 個人アクセストークンまたはサービスアカウントトークン。`single-user` モードでは必須です。`multi-user`、`oauth`、または `oauth-proxy` モードでは設定しないでください。各セッションで独自の認証情報を使用します
`HARNESS_ACCOUNT_ID`	いいえ	(PAT/SAT から取得)	Harness アカウント識別子。シングルユーザーモードでは PAT/SAT トークンから自動抽出されます。API キーにアカウント識別子が含まれていない場合、マルチユーザーセッションでは `x-harness-account-id` を使って独自の識別子を指定できます
`HARNESS_BASE_URL`	いいえ	`https://app.harness.io` (`oauth` および `oauth-proxy` では `https://mcp.harness.io/cli`)	Harness API/UI のベース URL。`oauth` と `oauth-proxy` はデフォルトでホスト型 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_MCP_OAUTH_CLIENT_SECRET`	はい*	--	Harness ID チームが発行する機密 HarnessID クライアントシークレット。`oauth-proxy` モードでのみ必須です
`HARNESS_MCP_OAUTH_EXTERNAL_SUB_CLAIM`	いいえ	`external_sub`	アカウント連携時に、上流の subject または上流のメールアドレスと照合する HarnessID トークンクレーム
`HARNESS_MCP_OAUTH_PROXY_GRANT`	いいえ	`refresh`	`oauth-proxy` モードでの後続リクエストの許可: `refresh` または `jwt-bearer`
`HARNESS_MCP_OAUTH_PROXY_PUBLIC_URL`	はい*	--	OAuth ブローカーの公開オリジン。`oauth-proxy` モードで必須であり、`HARNESS_MCP_OAUTH_RESOURCE` と同じオリジンである必要があります
`HARNESS_MCP_OAUTH_PROXY_VAULT_MODE`	いいえ	`file`	`file` は暗号化されたボールトをローカルディスクに保存し、1 つの Pod で使用します。`redis` は Pod 間でリフレッシュトークンとログイン状態を共有します
`HARNESS_MCP_OAUTH_PROXY_VAULT_PATH`	いいえ	`.harness-mcp/oauth-proxy-vault.enc`	ボールトモードが `file` の場合に使用する、暗号化された HarnessID トークンおよびログイン状態ファイル
`HARNESS_MCP_OAUTH_PROXY_VAULT_KEY`	はい*	--	`oauth-proxy` モードで必須の、Base64 エンコードされた 32 バイト AES キー
`HARNESS_MCP_OAUTH_PROXY_REDIS_URL`	はい*	--	ボールトモードが `redis` の場合に必須の `rediss://` URL。`redis://` には `HARNESS_ALLOW_HTTP=true` が必要です。Redis 6.2 以降
`HARNESS_MCP_OAUTH_PROXY_REDIS_KEY_PREFIX`	いいえ	`harness-mcp:oauth`	Redis 内の OAuth ボールトキーのプレフィックス
`HARNESS_MCP_UPSTREAM_ISSUER`	はい*	--	`oauth-proxy` モードで必須の、上流トークンの完全一致する発行者
`HARNESS_MCP_UPSTREAM_AUDIENCE`	はい*	--	`oauth-proxy` モードで必須の、上流トークンの完全一致するオーディエンス
`HARNESS_MCP_UPSTREAM_JWKS_URI`	いいえ	`<upstream issuer>/v1/keys`	上流 RS256 JWKS エンドポイント
`HARNESS_MCP_UPSTREAM_SCOPES`	いいえ	`openid profile email offline_access`	埋め込みブローカーが要求し、MCP クライアントに公開するスコープ
`HARNESS_MCP_UPSTREAM_OAUTH_CLIENT_ID`	はい*	--	埋め込みブローカーが使用する機密上流 OAuth クライアント
`HARNESS_MCP_UPSTREAM_OAUTH_CLIENT_SECRET`	はい*	--	サーバーのみが使用する上流 OAuth クライアントシークレット
`HARNESS_MCP_UPSTREAM_DISCOVERY_URI`	いいえ	`<upstream issuer>/.well-known/openid-configuration`	上流 OIDC ディスカバリーエンドポイント
`HARNESS_MCP_UPSTREAM_EMAIL_DOMAINS`	いいえ	--	カンマ区切りのドメイン。メールアドレスによる連携には `email_verified=true` と、このリスト内のドメインが必要です。リストが空の場合、メールアドレスによる連携は行われません
`HARNESS_MCP_BROKER_ISSUER`	いいえ	OAuth プロキシの公開 URL	MCP クライアントが検出する認可サーバーの発行者
`HARNESS_MCP_BROKER_CLIENT_ID`	いいえ	`cursor-harness-mcp`	公開 OAuth クライアント ID。MCP クライアントに同じ値を設定すれば、任意の名前を使用できます
`HARNESS_MCP_BROKER_REDIRECT_URIS`	いいえ	(空)	カンマ区切りのリダイレクト URI。空の場合、すべてのコールバックが拒否されます。`*` ではループバック `http`/`https` のみが許可されます。カスタムスキームは正確に列挙する必要があります
`HARNESS_MCP_BROKER_CODE_TTL_MS`	いいえ	`60000`	MCP クライアントに発行されるワンタイム認可コードの有効期間
`HARNESS_MCP_BROKER_TRANSACTION_TTL_MS`	いいえ	`600000`	連鎖するブラウザー認可トランザクションの最大有効期間
`HARNESS_FME_API_KEY`	いいえ	--	レガシー（`workspace_id`）モードのみで、`fme_` リソースに使用する任意のシングルユーザー／セルフホスト FME/Split Admin 認証情報。OAuth モードではレガシー FME を使用できないため、HarnessID トークンが `api.split.io` に送信されることはありません。代わりに Harness ネイティブの `org_id`+`project_id` スコープを使用してください。`multi-user`、`oauth`、または `oauth-proxy` モードでは設定しないでください
`HARNESS_FME_BASE_URL`	いいえ	`https://api.split.io`	レガシー（`workspace_id`）モードのみで、`fme_` リソースに使用する Split/FME Admin API のベース URL。HTTP URL をローカル開発で使用するには `HARNESS_ALLOW_HTTP=true` が必要です。Harness ネイティブ（`org_id`+`project_id`）モードでは無視され、代わりに標準の `HARNESS_API_KEY`/`HARNESS_BASE_URL` が使用されます
`HARNESS_APPSEC_API_KEY`	いいえ	--	`appsec_` リソース（`HARNESS_TOOLSETS=+appsec`）に使用する任意のシングルユーザー Traceable Platform API トークン。`HARNESS_API_KEY`、セッション `x-harness-api-key`、および HarnessID OAuth トークンが Traceable に転送されることはありません。`multi-user`、`oauth`、または `oauth-proxy` モードでは設定しないでください（ホスト型セッションではセッションごとに `x-harness-appsec-api-key` が提供されます）
`HARNESS_APPSEC_BASE_URL`	いいえ	`https://api.traceable.ai`	`appsec_` リソースに使用する Traceable GraphQL API のベース URL。HTTP URL をローカル開発で使用するには `HARNESS_ALLOW_HTTP=true` が必要です
`HARNESS_APPSEC_UI_URL`	いいえ	`https://app.traceable.ai`	`appsec_` リソースのディープリンクに使用する Traceable Web UI のベース URL（未設定の場合は `HARNESS_APPSEC_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 へのクライアント側リクエストスロットル（リクエスト/秒）
`LOG_LEVEL`	いいえ	`info`	ログの詳細度: `debug`、`info`、`warn`、`error`
`HARNESS_TOOLSETS`	いいえ	(デフォルト)	カンマ区切りのツールセット一覧。空の場合はデフォルトのツールセットが読み込まれます。`+name` を使ってオプトインのツールセットを明示的に含め、`-name` を使ってデフォルトを除外できます（ツールセットのフィルタリングを参照）
`HARNESS_READ_ONLY`	いいえ	`false`	すべての変更操作（作成、更新、削除、実行）をブロックします。一覧表示と取得のみが許可されます。共有／デモ環境に便利です
`HARNESS_SCHEMA_MODE`	いいえ	`compact`	`compact`（デフォルト）または `full`。Compact はツールごとのリソースタイプ列挙型を単純な文字列に置き換え、フィールドの説明を短縮することで、モデルに送信されるツール一覧を約半分に削減します（`docs/schema-budget.md` を参照）。タイプは `harness_describe` を使って検出されます。すべてのリソースタイプをインライン化するには `full` を設定します。
`HARNESS_MCP_APPS`	いいえ	`off`	MCP Apps ビュー。`off`（デフォルト）ではテキストのみの結果が維持されます。`auto` は `ui://harness/app` リソースを提供し、`io.modelcontextprotocol/ui` 拡張機能を宣言するホストに限り、`harness_get`、`harness_execute`、`harness_status` の結果にビューのデータを追加します。他のクライアントには変更されていないテキスト結果が返されます
`HARNESS_AUTO_APPROVE_RISK`	いいえ	`none`	自律型ワークフローにおけるリスクベースの自動承認しきい値。このリスク以下の操作は確認なしで実行されます。値: `none`、`low_write`、`medium_write`、`high_write`、`all`。Elicitation を参照
`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`	(アルファ版) Pipeline 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`）。サーバーの前段にあるプロキシの数を設定すると、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`	いいえ	--	監査 Webhook に送信する任意の Bearer トークン
`HARNESS_AUDIT_WEBHOOK_BATCH_SIZE`	いいえ	`10`	Webhook のフラッシュ前にバッチ処理する監査イベント数
`HARNESS_AUDIT_WEBHOOK_FLUSH_MS`	いいえ	`5000`	Webhook のフラッシュ前に監査イベントを保持する最大時間
`OTEL_EXPORTER_OTLP_ENDPOINT`	いいえ	--	オプションの OpenTelemetry パッケージがインストールされている場合に、OpenTelemetry 監査スパンを有効にします
`HARNESS_SEARCH_PROVIDER`	いいえ	`local`	セマンティック検索バックエンド: `local`（プロセス内 ONNX 埋め込み、デフォルト）、`remote`（HTTP 経由の外部検索サービス、マルチユーザーモードで必須）、または `none`（セマンティック検索を無効にし、キーワードの scatter-gather のみを使用）。エアギャップ環境、または起動時のモデル読み込みを避けたい場合は `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` が同時に実行するログ Blob のダウンロード数の上限。診断の遅延がログ取得の所要時間に支配され、Pod に十分なメモリ余裕がある場合に限り増やしてください

セマンティック検索

harness_search はセマンティックルーティングを使用して、Harness にファンアウトする前に scatter-gather API 呼び出しの範囲を絞り込みます。検索プロバイダーは次の 3 種類です。

プロバイダー	使用する場面
`local`（デフォルト）	単一ユーザーの stdio モード。`@huggingface/transformers` を介して `all-MiniLM-L6-v2` をプロセス内で実行します。初回使用時に約 23 MB のモデルをダウンロードし、以降の起動ではキャッシュを使用します。
`remote`	マルチユーザーの HTTP モード（Harness ホスト型）。埋め込みと検索を外部検索サービスに委譲します。テナント分離は `tenant_id` によって適用されます。静的なナレッジ／ドキュメントには `global` を、アカウントごとのエンティティデータにはアカウント ID を使用します。
`none`	セマンティック検索を完全に無効にし、すべてのリソースタイプを対象とするキーワードベースの scatter-gather にフォールバックします。

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

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 のコントラクトを実装しています。モデルのダウンロードが不要なように、単純な文字頻度ベースの埋め込みを使用します。そのため、結果は意味的には妥当ですが、本番品質ではありません。

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 は、HARNESS_AUDIT_WEBHOOK_TOKEN を任意で付けて、{ "events": [...] } のバッチを HTTPS Webhook に送信します。失敗したバッチは容量に上限のあるキューに再登録され、最終的にはツールの実行をブロックせず、警告を出して破棄されます。
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 はローカルメタデータのみを扱い、org/project スコープは使用しません。

URL のサポート： ほとんどの API 対応ツールは url パラメーターを受け付けます。Harness UI の URL を貼り付けると、サーバーが org、project、リソースタイプ、リソース ID、パイプライン ID、実行 ID を自動的に抽出します。harness_describe は url を受け付けません。

スコープのサポート： account/org/project の各バリアントを持つリソースタイプでは、harness_describe 内で supportedScopes を指定できます。特定のレベルが必要な場合は、resource_scope を渡してください。

resource_scope: "account" は accountIdentifier のみを送信します。
resource_scope: "org" は accountIdentifier と orgIdentifier を送信します。
resource_scope: "project" は account、org、project の識別子を送信します。

現在、複数のスコープに対応するリソースには、connector、service、environment、infrastructure、secret、file_store、template、policy、policy_set があります。resource_scope を省略すると、レジストリはリソースのデフォルトスコープと設定済みのデフォルト値を使用します。ただし、スコープが任意とされているリソースでは、明示的に渡さない限り org/project を省略できます。Harness URL のパスに account レベルまたは project レベルのコンテキストが含まれている場合、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`	1 回のクエリで Harness の複数のリソースタイプを横断検索します。セマンティックルーティング（ローカルの `all-MiniLM-L6-v2` ONNX 埋め込み、384 次元）を使用して、起動時にインデックス化された `knowledge` コーパスから関連するリソースタイプを予測し、通常は約 163 タイプから 1～8 タイプに絞り込んでから scatter-gather を実行します。セマンティック信頼度が低い場合は、全キーワードの scatter-gather にフォールバックします。ルーティングが実行された場合、レスポンスには `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 Management の定義（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 パイプラインがすでに存在し、アカウントレベルとパイプラインレベルの Allow Dynamic Execution が有効で、呼び出し元にパイプラインの Edit および Execute 権限が必要です。

{
  "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 が実行を有効化されていないとして拒否する場合は、アカウントレベルの Allow Dynamic Execution 設定と、Pipeline -> Advanced Options -> Dynamic Execution Settings にあるパイプラインレベルの切り替え設定の両方を確認してください。

実行入力のフォレンジック

実行後に 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 は get 専用で、読み取りリスクがあります。resolve_expressions を省略すると、サーバーは API クエリパラメーターを省略し、Harness はデフォルトの UNKNOWN 解決モードを使用します。

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

pipeline.run、pipeline.retry、pipeline_v1.run では、wait: true を渡すと、実行が終端ステータスに達するまでサーバーがポーリングします。これにより、クライアントや LLM にポーリングループを実行させることなく、パイプラインの起動とステータス確認を1回のツール呼び出しで行えます。

{
  "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 Agent にパイプラインの作成を依頼する:

{
  "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つの方法で保存できます。

モード	説明	使用する場面
Inline	パイプライン YAML を Harness に保存	デフォルト。最も簡単な設定で、Git は不要です。
Remote (External Git)	パイプライン YAML を GitHub、GitLab、Bitbucket などに保存	外部プロバイダーを使った Git 管理のパイプライン・アズ・コードを利用するチーム。
Remote (Harness Code)	パイプライン YAML を Harness Code リポジトリに保存	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"
  }
}

リモートパイプラインを作成する（External 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"
}

リソースタイプ

44のツールセットに分類された274のリソースタイプがあります。各リソースタイプは、CRUD 操作の一部と、任意の実行アクションをサポートします。

プラットフォーム

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`organization`	x	x	x	x	x
`project`	x	x	x	x	x

パイプライン

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`pipeline`	x	x	x	x	x	`run`, `retry`
`pipeline_v1` (Alpha)	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`

pipelines ツールセットが有効な場合、両方のパイプライン YAML リソースタイプを利用できます。HARNESS_PIPELINE_VERSION と HTTP の x-harness-pipeline-version 初期化ヘッダーは、デフォルトのバージョン優先設定を選択します。もう一方のバージョンが非表示になるわけではありません。

AI エージェント

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`agent`	x	x	x	x	x
`agent_run`	x

サービス

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`service`	x	x	x	x	x

環境

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`environment`	x	x	x	x	x	`move_configs`

コネクター

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`connector`	x	x	x	x	x	`test_connection`
`connector_catalogue`	x
`llm_model`	x

インフラストラクチャ

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`infrastructure`	x	x	x	x	x	`move_configs`

シークレット

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`secret`	x	x

実行ログ

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`execution_log`		x

監査証跡

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`audit_event`	x	x

デリゲート

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`delegate`	x	x
`delegate_token`	x	x	x		x	`revoke`, `get_delegates`

コードリポジトリ

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
`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 の list は ref にあるすべてのパスを返し、get はファイルまたはディレクトリの内容を返します（リポジトリのルートには 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 File Store のファイルとフォルダーを管理します。アカウント、組織、プロジェクトのスコープに対応しています。resource_scope="account"|"org"|"project" を渡すか、Harness File Store の 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）のいずれか一方だけを指定する必要があります。FILE の更新では、メタデータのみを更新する場合はコンテンツを省略できます。コンテンツを置き換える場合は、コンテンツフィールドを一つだけ指定してください。
FOLDER の作成/更新では、content と content_base64 を省略してください。
任意の file_usage は MANIFEST_FILE、CONFIG、または SCRIPT である必要があります。description、mime_type、path、tags などの任意のスカラー型メタデータは文字列である必要があります。
アップロードできるコンテンツの上限は 100 MB です。確認プロンプトでは、elicitation の前に 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 サービスのパス（/template/api/templates...）を使用します。作成と更新では、完全なテンプレート YAML 文字列を body.template_yaml または body.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 Management (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 です。任意フィールドを扱う場合は、取得してから PUT する方法を推奨します。書き込みは medium_write であり、確認（elicitation または 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="...") で plan、apply、destroy アクティビティのリソース差分を確認します。

IaCM の一覧応答では、page_count は現在のページのみの件数を示します（ページネーションされない iacm_variable_set を除く）。has_more が true の場合、次の 1 始まりのページを順にリクエストしてください。合計件数が必要な場合は、各ページの件数を合計します。

Internal Developer Portal (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	`resolve`, `unresolve`
`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 を使用します。

コメントスレッドを解決するには harness_execute(resource_type="pr_comment", action="resolve", ...) を、再開するには action="unresolve" を使用します。どちらも本文を受け取りません。comment_id には、pr_activity の行のうち、その行の parent_id が null であるものの id を指定する必要があります。API は返信 ID を拒否します。

リリース管理

Release Management (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_BASE_URL}/gateway/rmg を使用し、Harness-Account ヘッダーでアカウントスコープを指定します。org_id/project_id を指定すると、組織/プロジェクトスコープはヘッダーで指定されます。release_execution_phase は一覧専用です。各フェーズ項目の identifier フィールドを params.phase_identifier として使用し、フェーズの入力/出力リソースに対して harness_get を呼び出してください（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 に対して harness_get を使用します。各リソースの説明に従い、release_id と params.phase_identifier / params.activity_identifier / activity_execution_id を指定します。

統合検索

オプトインの unified-search ツールセット（HARNESS_TOOLSETS=+unified-search）を有効にすると、search-service が提供するすべてのソースを対象に、セマンティック（意味ベース）検索が追加されます。結果は呼び出し元のアカウントに限定され、RBAC によるフィルタリングが適用されます。アカウントでセマンティック検索の機能フラグを有効にする必要があります。

リソースタイプ	一覧	取得	アクションの実行
`unified_search`	x		`search`
`unified_search_source`		x

# 1. Search with the user's words (all sources)
harness_search(query="payments service that keeps crashing")

# 2. Optional: if a hit names a Knowledge Graph type, look it up or query it
harness_get(resource_type="kg_type", resource_id="<type id>", params={kind: "<kind>"})

# 3. Narrow with filters on the hits' metadata keys, per source
harness_execute(resource_type="unified_search", action="search", body={
  query: "payments service that keeps crashing",
  source_filters: {"<source>": {predicate: {field: "<metadata key>", op: "NE", values: [{string_value: "closed"}]}}}
})

harness_get(resource_type="unified_search_source") はソースの一覧を返します。フィルター構文については harness_describe(resource_type="unified_search") を参照してください。

これは、Semantic Search にあるセマンティックルーティングプロバイダーとは別の機能です。後者は MCP リソースの定義とドキュメントをインデックス化し、harness_search のファンアウトを絞り込みます。

Vibe

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

リソースタイプ	一覧	取得	作成	更新	削除	アクションの実行
`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 で許可されているとおり、追加の prepare フィールドはバックエンドの検証用に保持されます。準備処理は projectId、sourceId、upload を返します。これには各ファイルの uploadUrl、method、headers、expiresAt が含まれます。返された署名付き URL、メソッド、ヘッダーを使用して、ファイルのバイト列を直接アップロードしてください。URL はそのまま保持し、ストレージリクエストに Harness の認証情報を追加しないでください。prepare アクションはローカルファイルを読み取ったりアップロードしたりしません。

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

{
  "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 として使用されることはありません。インポートと prepare はアプリ/ソースを作成しますが、どちらもデプロイを開始しません。書き込みは自動再試行されず、デプロイには既存の高リスク操作の確認ポリシーが適用されます。

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

機能フラグ

リソースタイプ	一覧	取得	作成	更新	削除	アクションの実行
`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_experiment`	x	x	x	x	x
`fme_experiment_settings`		x		x	x
`fme_experiment_alerting`		x		x
`fme_experiment_result`	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 のみを組み合わせることはエラーです。呼び出しごとにいずれか一方のモードを選択してください。リソースが 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は、クエリパラメーターとしてenvironment_idを指定して/fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocateを呼び出します（任意の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を参照。）すべての操作（list/get/create/delete）でHarnessネイティブモードは拒否されます。代わりにfme_segmentを使用してください。このリソースがサポートするのはレガシーのworkspace_id契約のみです。
fme_rule_based_segment_definition — （非推奨 — fme_segment_definitionを参照。）すべての操作/アクション（list/update/enable/disable/change_request）でHarnessネイティブモードは拒否されます。代わりに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 — org_id+project_idを同時に渡した場合、create/updateはまだ実装されていません。それ以外の場合は通常のレガシー呼び出しとして処理されます。
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 execute 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に加え、execute 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にマッピングされます）。バックエンドのCreateMetricRequestでは省略可能（デフォルトはPER）ですが、createにはspreadが必須です。省略するとRATEメトリクスの意味が暗黙に変わるため、これはMCP側のみのより厳格な契約です。updateはJSON Merge Patchです。name/trafficTypeは変更不可で、受け付けられません。deleteは完全削除で、元に戻せません（アーカイブ/復元なし）。分類はdestructiveです。
fme_event_type — Harnessネイティブ専用（レガシーのworkspace_idはサポートされません）。読み取り専用です。list/getは/fme/api/v4/event-typesに接続されています。idはイベント名です。過去30日以内にイベントがあったイベントタイプのみ表示されます。要求元ワークスペースのトラフィックタイプのスコープ外にあるイベントタイプ、または30日を超えてイベントがないイベントタイプに対しては、getが404を返します。一覧のフィルター：name（部分一致）、traffic_type（IDまたは名前で検索）、offset/limit（harness_list sizeはlimitにマッピングされます）。IDを推測するのではなく、これを使って実際のイベントタイプIDを確認してから、fme_metricのbaseEventTypes/filterEventTypeまたはevent_type_idsフィルターで参照してください。
fme_experiment — Harnessネイティブ専用（レガシーのworkspace_idはサポートされません）。CRUDは/fme/api/v4/experimentsに接続されています。listにはparent_typeが必要です（FEATURE_FLAG、AI_CONFIG。CONFIGは404を返します）。statusが渡されない限り、デフォルトではACTIVE実験が対象です。createには、クエリパラメーターのenvironment_idと、本文のparent/name/startAt/endAt/baselineTreatment/comparisonTreatmentsが必要です。親はその環境に存在している必要があります。updateはJSON Merge Patchです。parentとenvironmentは変更できません。deleteは完全削除で、元に戻せません。分類はdestructiveです。作成/更新時のownersは任意です。各エントリーは{type: "USER", id or email}または{type: "GROUP", identifier}です。作成/更新時には、rule（ターゲティングルールのラベル結果のスコープ。省略時、作成では"default"がデフォルトになり、更新ではnullでクリアされます）と、tags（[{name}]。更新ではリスト全体が置き換えられ、null/[]でクリアされます）も任意で指定できます。listはtags配列フィルターを受け付けます（タグ名のいずれかを持つ実験）。項目にはtagsとruleが含まれます。
fme_experiment_settings — 単一の実験に関する統計およびモニタリング設定（テストタイプ、有意水準、多重比較補正、最小サンプルサイズ、レビュー期間、分散削減）。get/update/deleteのみです。実験と1対1で対応し、listはありません。getは常に適用済みの設定（独自のオーバーライドまたは組織のデフォルト）を返し、実験自体が存在しない場合を除いて404を返しません。updateはJSON Merge Patchで、実験レベルのオーバーライドを暗黙に作成します。deleteは組織のデフォルトに戻します（冪等）。永続的な操作ではありませんが、分類はdestructiveです。
fme_experiment_alerting — 単一の実験が有意性低下アラートを購読しているかどうかを示します。get/updateのみです。getは{id, isEnabled}を返し、アラートポリシーがない場合はisEnabled: falseを報告します。404を返すのは実験自体が存在しない場合のみです。updateはJSON Merge Patchで、isEnabledのブール値が必須です。
fme_experiment_result — 実験の最新計算実行における、メトリクスごとの評価結果。listのみです（結果自体に識別子がないため、getはありません）。すべてのメトリクスカテゴリにわたり、（メトリクス、比較対象の処置）の組み合わせごとに1行です。任意のフィルター：metric_ids、comparisons。最新の実行結果のみを反映し、過去の結果にはアクセスできません。

シングルユーザー/セルフホストモードでは、レガシーモードの認証に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の実行アクションに対応します。トラフィックタイプIDの確認にはfme_traffic_type、ID属性の作成/更新にはfme_identity、標準セグメントの確認とメンバーキーの追加にはfme_standard_segment / fme_segment_keysを使用します。fme_rule_based_segmentはターゲティングセグメントのCRUDを提供し、fme_rule_based_segment_definitionは環境固有のセグメントルールを管理し、有効化/無効化や変更リクエストの承認フローにも対応します。

GitOps

リソースタイプ	一覧	取得	作成	更新	削除	アクションの実行
`gitops_agent`	x	x
`gitops_agent_metrics`	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_experiment`	x	x	x	x	x	`run`, `stop`, `list_metadata`, `update_cron`
`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	x	x	`create_from_template`, `list_revisions`, `get_variables`, `get_yaml`, `compare_revisions`
`chaos_probe`	x	x	x		x	`list_metadata`, `enable`, `verify`, `get_manifest`
`chaos_probe_in_run`	x
`chaos_probe_template`	x	x	x	x	x	`get_variables`
`chaos_infrastructure`	x	x	x	x	x
`chaos_k8s_infrastructure`	x	x	x	x	x	`check_health`, `get_yaml`, `get_manifest`, `helm_command`
`chaos_enabled_infrastructure`	x
`chaos_environment`	x
`chaos_hub`	x	x	x	x	x	`list_metadata`
`chaos_hub_fault`	x
`chaos_fault`	x	x			x	`list_metadata`, `get_variables`, `get_yaml`
`chaos_fault_template`	x	x	x	x	x	`list_revisions`, `get_variables`, `get_yaml`, `compare_revisions`
`chaos_fault_experiment_run`	x
`chaos_action`	x	x	x	x	x	`list_metadata`, `get_manifest`
`chaos_action_template`	x	x	x	x	x	`list_revisions`, `get_variables`, `compare_revisions`
`chaos_loadtest`	x	x	x	x	x	`run`, `stop`, `estimate_workers`, `convert_har`
`chaos_loadtest_run`	x	x				`status`, `live_metrics`, `ai_insights`, `generate_ai_insights`
`chaos_service`	x	x	x	x	x	`list_experiment_runs`, `list_load_tests`
`custom_service`	x	x	x	x
`chaos_application_map`	x	x			x
`discovered_agent`	x
`discovered_namespace`	x
`discovered_service`	x
`discovered_network_map`	x
`chaos_guard_condition`	x	x	x	x	x
`chaos_guard_rule`	x	x	x	x	x	`enable`
`chaos_recommendation`	x	x
`chaos_onboarding`	x	x	x		x	`stats`, `confirm_discovery`, `onboard_services`, `confirm_service_onboarding`, `trigger_risk_scan`, `risk_scan`, `confirm_risk_scan`, `list_services`, `confirm_network_map`, `confirm_experiment_creation`, `confirm_experiment_run`, `skip`, `stop`
`chaos_pipeline_onboarding`	x	x	x		x	`can_onboard`
`chaos_risk`	x	x
`chaos_dr_test`	x		x
`scanned_risk`	x	x				`occurrences`, `summary_by_service`
`chaos_risk_rule`	x	x	x	x	x
`chaos_risk_scan`	x	x	x	x	x	`retry`, `abort`, `report`, `report_download`, `heatmap`, `submit_findings`
`chaos_dashboard`	x	x		x
`chaos_image_registry`		x	x	x		`resolve`

クラウドコスト管理 (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 の params を使用してください。

リソースタイプ	一覧	取得	アクションの実行
`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、get の場合は 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

Evidence Vault

Evidence Vault は in-toto アテステーション (SDLC エビデンス) を保存します。一覧表示では、resource_scope を使用してアカウント/組織/プロジェクトのスコープを指定できます。単一のフリーテキストフィルター (pipeline、artifact 単独、gitoid) には search_term を使用します。追加の Name 制約には filters.subject_name を使用し、subject content digest には 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 promote エンドポイントを使用します。省略された場合、サーバーは認証済みユーザーから body.approver_id を自動入力します。body.comment は任意です。
免除を却下するには action="reject" を使用します。省略された場合、body.approver_id も自動入力されます。
個別の promote 実行アクションはありません。アカウント、組織、またはプロジェクトのスコープでの承認が求められている場合は、action="approve" を非 CURRENT の body.scope とともに使用します。

アクセス制御

リソースタイプ	一覧	取得	作成	更新	削除
`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

プロンプト	説明	パラメーター
`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

プロンプト	説明	パラメーター
`optimize-costs`	クラウドコストデータを分析し、削減可能額の大きさに基づいて優先順位を付け、推奨事項と異常を提示します	`projectId` (任意)
`cloud-cost-breakdown`	サービス、環境、またはクラスター別にクラウドコストを詳しく分析し、傾向分析と異常検出を行います	`perspectiveId` (任意), `projectId` (任意)
`commitment-utilization-review`	リザーブドインスタンスと Savings Plans の利用状況を分析し、無駄を特定してコミットメントを最適化します	`projectId` (任意)
`cost-anomaly-investigation`	コスト異常を調査し、根本原因、影響を受けたリソース、修正方法を特定します	`projectId` (任意)
`rightsizing-recommendations`	ライツサイジングの推奨事項を確認して優先順位を付け、必要に応じて Jira または ServiceNow のチケットを作成します	`projectId` (任意), `minSavings` (任意)

DevSecOps

プロンプト	説明	パラメーター
`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` (必須), issue filters (任意)
`access-control-audit`	最小権限の原則を徹底するため、ユーザー権限、過剰な権限を持つアカウント、ロール割り当てを監査します	`projectId` (任意), `orgId` (任意)

Harness

Prompt	説明	パラメーター
`code-review`	プルリクエストをレビューする — 差分、コミット、チェック、コメントを分析し、バグ、セキュリティ、パフォーマンス、スタイルに関する構造化されたフィードバックを提供する	`repoId` (必須), `prNumber` (必須), `projectId` (任意)
`pr-summary`	ブランチのコミット履歴と差分から 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 Schema	`application/schema+json`
`schema:///template`	Harness テンプレート JSON Schema	`application/schema+json`
`schema:///trigger`	Harness トリガー JSON Schema	`application/schema+json`
`schema:///pipeline_v1` (Alpha)	Harness V1 パイプライン JSON Schema（簡略化されたステージ/ステップ形式）	`application/schema+json`
`schema:///agent-pipeline`	Harness AI エージェントパイプライン JSON Schema	`application/schema+json`
`agent-docs:///legacy-format`	レガシーエージェント仕様形式のリファレンス（`agent.step.group.steps` / `PLUGIN_TASK`）。既存のレガシー形式エージェントを更新する際に、`create-agent` プロンプトによって読み込まれる	`text/markdown`

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

デフォルトでは、50 個中 44 個のツールセットが有効です。5 個のツールセットはオプトイン方式で、デフォルトでは除外されています。

ansible — Harness Ansible（インベントリ、プレイブック、ホスト、アクティビティ）。プロジェクトスコープであり、多くのユーザーが必要としない概念が追加されるため、オプトイン方式です。
appsec — Traceable Application & API Security（API インベントリ、OpenAPI 仕様、サンプルスパン、機密データ型、ランタイム脅威アクティビティ、セキュリティイベント、AST スキャン、インベントリの傾向）。専用の HARNESS_APPSEC_API_KEY が必要で、api.traceable.ai を対象とするため、オプトイン方式です。
autonomous_work — Development Harness（自律的な作業）。オプトイン方式です。対象範囲についてはツールセットの説明を参照してください。
observability-evaluations — 本番テレメトリ評価ルールのスケジュール設定。デプロイ済みのスコアリングコントロールプレーンに依存するため、オプトイン方式です。
unified-search — search-service が提供するすべてのソースを対象としたセマンティック検索。バックエンドがすべてのクラスターにデプロイされているわけではなく、アカウントごとに機能フラグで制御されるため、オプトイン方式です（Unified Search を参照）。
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, llm_model
`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, fme_experiment, fme_experiment_settings, fme_experiment_alerting, fme_experiment_result
`gitops`	gitops_agent, gitops_agent_metrics, 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_loadtest_run, chaos_service, custom_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_onboarding, chaos_pipeline_onboarding, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan, chaos_dashboard, chaos_image_registry
`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`	設定
`knowledge-graph`	kg_queryable_type_summary, kg_grammar, hql_query
`semantic-layer`	kg_type, kg_related_type
`unified-search` (オプトイン)	unified_search, unified_search_source
`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_git_registration, eval_prompt, online_eval
`observability-evaluations` (オプトイン)	observability_eval
`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
`timelines`	activity_timeline
`appsec` (オプトイン)	appsec_api, appsec_api_spec, appsec_api_span, appsec_entity, appsec_vulnerability, appsec_threat_activity, appsec_security_event, appsec_ast_scan, appsec_inventory_trend, appsec_datatype

アーキテクチャ

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

仕組み

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

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

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` 以下）	いずれでも可	いずれでも可	確認なしで自動承認

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

自律モード

自律モードでは、サーバーは確認を求めず、書き込みや破壊的操作を含むすべての操作を実行します。次の設定を行って有効にします。

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 サーバーを標的とする悪意あるウェブサイトからの CSRF 攻撃を防ぎます。
HTTP のレート制限。 HTTP トランスポートは、リクエストの集中を防ぐため、IP ごとに毎分 60 リクエストを上限とします。
API のレート制限。 Harness API クライアントは、上流のレート制限に達しないよう、毎秒 10 リクエストを上限とします。
ページネーションの上限を適用します。 メモリ枯渇を防ぐため、リストクエリは合計 10,000 件、1 ページあたり 100 件を上限とします。
バックオフ付きの再試行。 一時的な障害（HTTP 429、5xx）は、指数バックオフとジッターを使って再試行されます。
localhost へのバインド。 HTTP トランスポートはデフォルトで 127.0.0.1 にバインドされ、ネットワークからはアクセスできません。
stdout へのログ出力なし。 stdio JSON-RPC トランスポートを破損させないよう、すべてのログは stderr に出力されます。

トラブルシューティングとよくある落とし穴

症状	考えられる原因	対処方法
`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 つ以上のツールセット名が認識されない	ツールセットのフィルタリングに記載された名前のみを使用する（完全一致）
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` を実行する前に、終端ステータスになるまで待つ
実行ログが空、または blob のダウンロードで 403 が返される	Harness がホストするログ blob 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`	クライアントが elicitation をサポートしていない、`elicitInput` が失敗した、または退化した accept が返された	非対話型の自動化では `confirm: true` を使って再試行するか、elicitation をサポートするクライアントを使用する
テンプレートの作成／更新での `body.template_yaml (or body.yaml) is required`	テンプレート API では完全な YAML ペイロードが必要	`body` に完全な `template_yaml` 文字列を指定する。削除する場合は、1 つのバージョンを削除するために `version_label` を渡す（省略するとすべてのバージョンを削除）
起動時の `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 Server を使う理由

前提条件

クイックスタート

オプション 0: Hosted Harness MCP

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

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

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

Anthropic MCP Directory バンドル

CLI の使用方法

HTTP トランスポート

HarnessID OAuth モード

上流 ID プロバイダー OAuth プロキシモード

マルチユーザーモード

クライアント設定

Hosted Harness MCP

Claude Desktop (claude_desktop_config.json)

Claude Code（claude mcp add 経由）

Cursor (.cursor/mcp.json)

Devin Desktop (~/.windsurf/mcp.json)

MCP Gateway

Docker MCP Gateway

Portkey

LiteLLM

Envoy AI Gateway

Kong

その他のゲートウェイ

Docker

Kubernetes

設定

セマンティック検索

HTTPS の強制

監査ログ

ツールリファレンス

スキーマ参照ワークフロー

ツールの例

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

動的パイプライン実行

実行入力のフォレンジック

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

パイプラインの保存モード

リソースタイプ

プラットフォーム

パイプライン

AI エージェント

サービス

環境

コネクター

インフラストラクチャ

シークレット

実行ログ

監査証跡

デリゲート

コードリポジトリ

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

ファイルストア

テンプレート

ダッシュボード

データベース DevOps

Infrastructure as Code Management (IaCM)

Internal Developer Portal (IDP)

プルリクエスト

リリース管理

統合検索

Vibe

機能フラグ

GitOps

カオスエンジニアリング

クラウドコスト管理 (CCM)

ソフトウェアエンジニアリングインサイト (SEI)

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

Evidence Vault

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

アクセス制御

ガバナンス

デプロイメント凍結

サービスオーバーライド

Claude Desktop (`claude_desktop_config.json`)

Claude Code（`claude mcp add` 経由）

Cursor (`.cursor/mcp.json`)

Devin Desktop (`~/.windsurf/mcp.json`)

`+` プレフィックスを使ったツールセットの追加