Harness

Harness MCP Server 2.0

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

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

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

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

• 11 個のツール、263 種類のリソース。 レジストリベースのディスパッチシステムにより、harness_list、harness_get、harness_create などをパイプライン、サービス、環境、組織、プロジェクト、フィーチャーフラグ、コストデータなど、あらゆる Harness リソースに振り分けます。LLM は数百個ではなく、11 個のツールから選択します。
• プラットフォーム全体を網羅。 CI/CD、GitOps、フィーチャーフラグ、クラウドコスト管理、セキュリティテスト、カオスエンジニアリング、データベース DevOps、内部開発者ポータル、ソフトウェアサプライチェーン、Infrastructure as Code 管理、リリース管理、ガバナンス、サービスオーバーライド、ナレッジグラフなど、42 個のデフォルトのツールセットを提供します。必要に応じて、オプトインで Ansible とオブザーバビリティ評価にも対応できます。
• 複数プロジェクトのワークフローに標準で対応。 エージェントは組織とプロジェクトを動的に検出するため、環境変数をハードコードする必要はありません。「すべてのプロジェクトで失敗した実行を表示して」と依頼すれば、エージェントはアカウントの階層全体をたどれます。
• 35 個のプロンプトテンプレート。 アプリのビルドとデプロイの一貫した実行、失敗したパイプラインのデバッグ、DORA メトリクスのレビュー、脆弱性のトリアージ、クラウドコストの最適化、アクセス制御の監査、フィーチャーフラグのロールアウト計画、プルリクエストのレビュー、保留中のパイプラインの承認など、一般的なワークフロー向けの事前構築済みプロンプトを用意しています。
• あらゆる環境で動作。 ローカルクライアント（Claude Desktop、Cursor、Devin Desktop）向けの Stdio トランスポート、リモートまたは共有デプロイメント向けの HTTP トランスポートに対応し、Docker と Kubernetes にも対応しています。
• 設定不要ですぐに開始。 Harness API キーを指定するだけです。PAT と SAT トークンからアカウント ID が自動抽出され、組織とプロジェクトのデフォルト設定は任意です。ツールセットを絞り込んで、必要なものだけを公開できます。
• 拡張性を考慮した設計。 新しい Harness リソースを追加するには、宣言型データファイルを追加するだけです。新しいツールの登録、スキーマの変更、プロンプトの更新は不要です。

前提条件

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

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

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

クイックスタート

オプション 0：ホスト型 Harness MCP

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

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

設定例については、ホスト型 Harness MCPを参照してください。

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

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

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

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

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

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

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

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

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

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

開発またはカスタマイズを行う場合：

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

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

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

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

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

pnpm prepare:mcpb

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

v*.*.* に一致するバージョンタグを付けると、そのバンドルが対応する GitHub Release に自動で公開されます。npm を再公開せずに既存のリリースを補完するには、release_tag 入力（例：v3.2.20）を指定して Release ワークフローを手動で実行します。このワークフローは、指定されたタグをチェックアウトしてビルドした後、そのバージョンの 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 エンドポイント（初期化＋セッションリクエスト）
/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）。
• HTTP セッションで V0 または V1 のパイプラインリソースを選択するには、initialize リクエストに x-harness-pipeline-version: 0 または 1 を設定します。
• セッションごとに、より厳しい自動承認しきい値を選択するには、initialize リクエストに x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all を設定します。サーバーはこの値をデプロイメントレベルの HARNESS_AUTO_APPROVE_RISK 以下に制限するため、セッションでは設定済みの承認上限を引き下げることはできますが、引き上げることはできません。

HarnessID OAuth モード

HARNESS_MCP_MODE=oauth を設定すると、リモート MCP クライアントが HarnessID を検出し、PKCE を使用した OAuth 2.1 Authorization Code フローを完了できるようになります。OAuth モードは HTTP トランスポートでのみ利用できます。本番環境向けの HarnessID、MCP リソース、API ルーティングのデフォルト値が組み込まれています。

HARNESS_MCP_MODE=oauth

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

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

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

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

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

アカウント ID は、トークンの HARNESS_MCP_OAUTH_ACCOUNT_CLAIM クレーム（デフォルトでは account_id）から取得されます。この値は HarnessID の organization スコープによって設定されます。各セッションには呼び出し元のアクセストークンが保存され、Harness API へのリクエストでは Authorization: Bearer として転送されます。これにより、共有 PAT ではなくログイン中のユーザーが Harness RBAC と監査記録に反映されます。セッションは作成時の 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 専用です。また、上流の発行者とオーディエンス、および安定した 32 バイトのボールトキーが必要です。設定方法と MCP のエンドツーエンドテストコマンドについては、 上流 ID プロバイダー OAuth プロキシモードを参照してください。

マルチユーザーモード

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

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

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

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

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

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

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

クライアント設定

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

ホステッド Harness MCP

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

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

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

ホステッド MCP の例：

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

ホステッドとローカルの両方を登録する例：

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

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

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

GUI アプリ（Cursor、Claude Desktop、Devin Desktop、VS Code）は、シェルの PATH を常に引き継ぐわけではないため、設定の再読み込み後に npx や node が見つからず失敗することがあります。絶対パスを使用し、env ブロックで PATH を明示的に設定すると解決できます。

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

ターミナルで which npx と which node を実行してパスを確認し、node があるディレクトリが上記の PATH の値に含まれていることを確認してください。一般的な場所：

• Homebrew（macOS）： /opt/homebrew/bin/npx
• nvm： ~/.nvm/versions/node/v20.x.x/bin/npx（正確なパスを確認するには nvm which current を実行します）
• システム Node： /usr/local/bin/npx

Claude Desktop（claude_desktop_config.json）

npx（インストール不要）

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

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

npm install -g harness-mcp-v2

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

Claude Code（claude mcp add経由）

npx（インストール不要）

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

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

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

環境または.envファイルでHARNESS_API_KEYを設定してください。

Cursor（.cursor/mcp.json）

npx（インストール不要。ローカルのCursor設定での使用を推奨）

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

ターミナルでwhich npxを実行し、そのフルパスをcommandに指定してください。また、which nodeで表示されるディレクトリをPATHの先頭に追加してください。

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

npm install -g harness-mcp-v2

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

npm install -g harness-mcp-v2の実行後にwhich harness-mcp-v2を実行し、そのフルパスをcommandに指定してください。また、which nodeで表示されるディレクトリをPATHの先頭に追加してください。

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

npx（インストール不要）

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

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

npm install -g harness-mcp-v2

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

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

コマンドを、ビルドしたindex.jsへのパスに置き換えてください。

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

MCP ゲートウェイ

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

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

• 認証情報の一元管理 — エージェント設定に 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のルーティングを利用するには、Harness MCP サーバーをPortkey MCP Gatewayに追加します。

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

LiteLLM

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

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

Envoy AI Gateway

サーバーはHTTPトランスポートを介して、Envoy AI GatewayのMCPサポートと連携します。

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

次に、Envoyで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

デプロイでは、レディネス／ライブネスプローブ、リソース制限、非rootのセキュリティコンテキストを設定して、レプリカを2つ実行します。Serviceは内部でポート80を公開し、コンテナのポート3000を転送先とします。

設定

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

変数	必須	デフォルト	説明
HARNESS_MCP_MODE	いいえ	single-user	デプロイモード：single-user、multi-user、oauth（HarnessID トークンを直接使用）、または oauth-proxy（上流の ID プロバイダートークンをユーザーごとの HarnessID トークンと交換）
HARNESS_API_KEY	はい*	--	Harness の個人アクセストークンまたはサービスアカウントトークンです。single-user モードでは必須です。multi-user、oauth、oauth-proxy モードでは設定しないでください。これらのモードでは各セッションが独自の認証情報を持ち込みます
HARNESS_ACCOUNT_ID	いいえ	(PAT/SAT から取得)	Harness アカウント識別子です。single-user モードでは PAT/SAT トークンから自動抽出されます。API キーにアカウント ID が含まれていない場合、multi-user セッションでは x-harness-account-id を使用して独自の 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	リンク時に上流のサブジェクトまたは上流のメールアドレスと照合される 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 は暗号化されたボールトをローカルディスクに保存し、単一のポッドで使用します。redis はポッド間でリフレッシュトークンとログイン状態を共有します
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 クライアントに発行される、1 回限りの認可コードの有効期間
HARNESS_MCP_BROKER_TRANSACTION_TTL_MS	いいえ	600000	ブラウザー認可の連鎖トランザクションの最大有効期間
HARNESS_FME_API_KEY	いいえ	--	レガシー（workspace_id）モードのみで fme_ リソースに使用する、オプションの single-user／セルフホスト型 FME/Split Admin 認証情報です。レガシー FME は OAuth モードでは利用できないため、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_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_AUTO_APPROVE_RISK	いいえ	none	自律型ワークフローで使用する、リスクベースの自動承認しきい値です。このリスク以下の操作は確認なしで進みます。値：none、low_write、medium_write、high_write、all。確認要求を参照してください
HARNESS_SKIP_ELICITATION	いいえ	false	非推奨 — 代わりに HARNESS_AUTO_APPROVE_RISK=all を使用してください。後方互換性のために保持されています
HARNESS_ALLOW_HTTP	いいえ	false	HTTPS 以外の HARNESS_BASE_URL を許可します。デフォルトでは、セキュリティのためサーバーは HTTPS を強制します。TLS 非対応の Harness インスタンスを対象としたローカル開発でのみ true に設定してください
HARNESS_PIPELINE_VERSION	いいえ	0	（アルファ版） 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 トークンです。ループバック以外への single-user および multi-user のバインドでは、デフォルトで必須です。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 経由の外部検索サービス。multi-user モードでは必須）、または none（セマンティック検索を無効にし、キーワードのスキャッターギャザーのみを使用）。エアギャップ環境や、起動時のモデル読み込みを避けたい場合は none を使用してください
HARNESS_SEARCH_SERVICE_URL	いいえ	--	HARNESS_SEARCH_PROVIDER=remote の場合に使用するリモート検索サービスのベース URL（例：http://search-svc:8080）です。remote プロバイダーを使用する場合は必須です
HARNESS_SEARCH_SERVICE_HEADERS	いいえ	--	リモート検索サービスへのすべてのリクエストに付加するヘッダーを含む JSON オブジェクトです。あらゆる認証方式に対応します：{"Authorization":"Bearer tok"}、{"x-api-key":"key"}、または複数の内部サービス間ヘッダー
HARNESS_HF_CACHE_DIR	いいえ	/tmp/hf-cache	local 検索プロバイダーが使用する @huggingface/transformers モデルキャッシュのディレクトリです。Docker イメージでは実行時のダウンロードを避けるため、モデルが /app/.cache/hf にあらかじめ組み込まれています。本番環境へのデプロイでは、永続ボリュームのパスを設定してください
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	いいえ	3	失敗したステップのログ取得時に harness_diagnose が実行する、ログ Blob ダウンロードの最大同時実行数です。診断の遅延の主な原因がログ取得にかかる時間であり、ポッドにメモリの余裕がある場合にのみ増やしてください

セマンティック検索

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）は、構造化監査イベントを出力します。変更を伴うイベントには、確認コンテキストが存在する場合、エリシテーションまたは自動承認で使用された確認方法が含まれます。読み取りイベントには、現時点では確認メタデータは含まれません。harness_describe や harness_schema など、レジストリを経由しないローカルのメタデータおよびスキーマ検出ツールは、この監査ストリームの対象外です。デフォルトでは stderr シンクが登録されますが、通常のロガーを経由し、LOG_LEVEL に従います。監査イベントを永続的に収集するには、ファイルシンクまたは Webhook シンクを設定してください。

• HARNESS_AUDIT_FILE は、ローカル収集用に改行区切りの JSON イベントを追記します。
• HARNESS_AUDIT_WEBHOOK_URL は、{ "events": [...] } 形式のバッチを HTTPS Webhook に送信します。HARNESS_AUDIT_WEBHOOK_TOKEN は任意で指定できます。送信に失敗したバッチは、容量に上限のあるキューに再登録されます。最終的に警告を出して破棄されますが、ツールの実行をブロックすることはありません。
• OTEL_EXPORTER_OTLP_ENDPOINT は、オプションの OpenTelemetry ピア依存関係がインストールされている場合に監査スパンを有効にします。シンクは、登録済みのトレーサープロバイダーがあればそれを再利用し、なければスタンドアロンの OTLP エクスポーターを初期化します。

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

ツールリファレンス

このサーバーは 11 個の MCP ツールを公開します。ほとんどの API ツールでは、org_id と project_id をオプションの上書き値として指定できます。省略した場合は、HARNESS_ORG と HARNESS_PROJECT にフォールバックします。harness_describe はローカルのメタデータのみを扱い、組織／プロジェクトのスコープは使用しません。

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

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

• resource_scope: "account" は accountIdentifier のみを送信します。
• resource_scope: "org" は accountIdentifier と orgIdentifier を送信します。
• resource_scope: "project" はアカウント、組織、プロジェクトの各識別子を送信します。 現在、複数のスコープを持つリソースには connector、service、environment、infrastructure、secret、file_store、template、policy、policy_set があります。resource_scope が省略されると、レジストリはリソースのデフォルトスコープと設定済みのデフォルト値を使用します。ただし、スコープが任意のリソースでは、明示的に渡されない限り org/project を省略できます。Harness URL のパスにアカウントレベルまたはプロジェクトレベルのコンテキストが含まれている場合も、スコープを自動的に設定できます。

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

Tool	説明
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 タイプに絞り込みます。セマンティック信頼度が低い場合は、全タイプを対象とするキーワードのスキャッターギャザーにフォールバックします。ルーティングが行われた場合、レスポンスには 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 を取得します（同梱されていません）。org または project をスコープとして指定する場合は、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 パイプラインでは、実行時の入力エラーを減らすため、次の手順を使用してください。

1. 必要な実行時入力を確認する

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

2. 入力方法を選択する

• シンプルな変数： フラットなキーと値の 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 が優先されます）。

3. 実行を開始する

• 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
  }
  

4. 任意：両方を組み合わせる

• ベースの構造には input_set_ids を、シンプルなオーバーライドには inputs を使用します。

v1 パイプラインの場合：

1. harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>") を取得します。 Git 管理のパイプラインでは、branch_name、connector_ref、repo_name を params 経由で渡します。
2. 返された各 inputs[].details.name を、harness_execute.inputs のトップレベルキーとして使用します。
3. 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 が有効になっている必要があります。また、呼び出し元にはパイプラインの編集権限と実行権限が必要です。

{
  "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 フィールドを含むオブジェクトである必要があります。生の文字列の body は、公開 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 を渡すと、実行が終端ステータスに達するまでサーバーがポーリングします。これにより、パイプラインの起動とステータス確認を 1 回のツール呼び出しにまとめられるため、クライアントまたは LLM がポーリングループを実行する必要がありません。

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

待機モードの動作：

• デフォルトのタイムアウトは 600 秒で、指定可能な範囲は 10 秒から 7200 秒です。
• 初回のポーリング間隔はデフォルトで 3 秒です。1.5 倍ずつ延長され、上限は 30 秒です。
• 成功または失敗時のレスポンスには、execution_id、execution_status、execution_terminal、execution_elapsed_ms、execution_poll_count などのフィールドが含まれます。
• タイムアウトが発生しても、元のトリガーは成功しています。レスポンスには execution_timed_out: true と、最後に確認されたステータスを含む _wait.hint が含まれます。
• トリガーの成功後にポーリングが失敗した場合、レスポンスには _wait.error と再確認のヒントが含まれます。最初の実行が動作中でないことを確認せずに、パイプラインをむやみに再実行しないでください。
• 失敗の終端ステータスには、harness_diagnose(resource_type="execution", options={execution_id: "..."}) を示す _diagnose_hint が含まれます。

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

モード	説明	使用する場面
インライン	パイプライン YAML を Harness に保存します	デフォルトです。最も簡単に設定でき、Git は不要です。
リモート（外部 Git）	パイプライン YAML を GitHub、GitLab、Bitbucket などに保存します	外部プロバイダーを使った Git ベースのパイプライン・アズ・コードを利用するチーム向けです。
リモート（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"
  }
}

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

リソースタイプ

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

プラットフォーム

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

パイプライン

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

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

AI エージェント

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

サービス

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

環境

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

コネクター

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

インフラストラクチャ

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

シークレット

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

実行ログ

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

監査証跡

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

委任先

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

コードリポジトリ

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

commit の作成では、クローンせずに Harness Code API を通じて、1 つ以上のファイル操作を直接コミットします。body.title、body.branch、body.actions を指定してください。各操作は CREATE、UPDATE、DELETE、または MOVE です。UPDATE には現在の blob SHA が必要です。

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

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

リソースタイプ	一覧	取得	作成	更新	削除	アクションの実行
registry	x	x
artifact	x
artifact_version	x
artifact_file	x

ファイルストア

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

file_store は、汎用ツールを通じて Harness 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 です。確認プロンプトでは、入力要求の前に 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 のキャメルケース 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 が使用され、確認（エリシテーションまたは 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

一般的なワークフロー：

1. harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") を使ってワークスペースを検索します。
2. iacm_workspace に対して harness_create ／ harness_update を実行し、ゼロから、またはテンプレート（associated_template）から作成するか、既存のワークスペースを更新します。応答は { policy_evaluation } のみです。
3. harness_get(resource_type="iacm_workspace", workspace_id="...") を使って、作成または更新したワークスペースを取得します。
4. 再利用可能な Terraform ／ env 変数セットには、iacm_variable_set に対して harness_list ／ harness_create ／ harness_update を実行します（必要に応じて resource_scope を指定）。応答は VariableSet リソースです。
5. モジュールレジストリには、iacm_module に対して harness_list ／ harness_create ／ harness_update を実行します（name と system が必須です。組織またはプロジェクトのスコープを設定したモジュールの場合は、org_id ／ project_id を含む resource_scope を追加します）。応答は module リソースです。
6. アカウントのプロバイダーレジストリには、iacm_provider に対して harness_list ／ harness_create ／ harness_update を実行します（作成時は body.type が必須です。作成時の応答は { id } のみなので、その後 harness_get を実行します。更新ではバージョンのみを作成／更新します）。バージョンの更新では、成功しても応答が空の場合があります。
7. harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") を使って、Terraform のリソース、出力、データソースを調べます。
8. harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") を使って、実行ごとのコスト項目を確認します。
9. 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 始まりのページを引き続きリクエストし、各ページの件数を合計してください。

内部開発者ポータル（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 には、parent_id が null である pr_activity の行の id を指定する必要があります。API は返信の ID を拒否します。

リリース管理

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

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

リソースタイプ	一覧表示	取得	作成	更新	削除	アクションの実行
release_process	x	x	x	x	x
release_activity	x	x	x	x	x
release	x	x
release_execution_phase	x
release_execution_task	x
release_execution_activity	x
release_input		x
release_execution_phase_input		x
release_execution_phase_output		x
release_execution_activity_input		x
release_execution_activity_output		x

一般的なワークフロー：

1. harness_list(resource_type="release_process", org_id="...", project_id="...") を実行して、オーケストレーションプロセスの定義を確認します。
2. 作成／更新の前に harness_schema(resource_type="release_process")（または release_activity）を実行し、その後 body.yaml を指定して harness_create／harness_update を実行します。
3. harness_list(resource_type="release", org_id="...", project_id="...") を実行して、アクティブまたは最近のリリースを確認します（デフォルトでは過去 30 日間を対象とします。filters.status、filters.search_term、filters.days_back は任意で指定できます）。
4. harness_get(resource_type="release", release_id="...") を実行して、リリースの詳細を取得します。
5. harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) を実行してフェーズのステータスを確認します。release_execution_task と release_execution_activity でも同じ release_id を使用します。
6. 各リソースの説明に記載されているとおり、release_id と params.phase_identifier／params.activity_identifier／activity_execution_id を指定して、release_input、release_execution_phase_input、release_execution_phase_output、release_execution_activity_output、または release_execution_activity_input に対して harness_get を実行します。

バイブ

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

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

API では、2 つの取り込み方法がサポートされています。以下の API 固有のリクエスト形式を使用してください。

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

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

既存の ZIP を使用する場合は、アップロードを準備します。

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

これを harness_execute に渡します。サイズは実際の ZIP のサイズを示す必要があります。size_bytes、content_type、md5 は任意で、null を指定できます。OpenAPI で許可されている追加の prepare フィールドは、バックエンドの検証用に保持されます。準備処理では projectId、sourceId、および各ファイルの uploadUrl、method、headers、expiresAt を含む upload が返されます。署名付き 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 のワイヤーフィールドはスネークケースの project_id ですが、prepare ではキャメルケースの projectId が返されます。汎用ツールのトップレベルの project_id は Harness のスコープ識別子であり、Vibe アプリ ID として使用されることはありません。インポートと prepare はアプリ／ソースを作成しますが、どちらもデプロイを開始しません。書き込みは自動的に再試行されず、デプロイには既存の高リスク確認ポリシーが適用されます。 harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>") で進捗を確認できます。アプリの URL、実行ステージ、サブステップ、失敗、ログ行、ビルドアナライザーの詳細が保持されます。events の実行アクションは 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 の仕様はありませんでした。ネイティブの list では、オプションの offset／limit（最大 100）を使用します。harness_list の size は limit にマッピングされます。エンベロープ {data, limit, offset, totalCount} は items／total に変換されます。ネイティブの create／update では isProduction を使用します（production もエイリアスとして受け付けます）。ネイティブの update は JSON Merge Patch です。name と isProduction はクリアできません。名前の最大文字数は 15 文字です。
• fme_feature_flag — デュアルモードで、両方の分岐に完全対応しています。Harness ネイティブ（org_id＋project_id）では、list／get／create／delete は /fme/api/v4/feature-flags にアクセスします（create の本文は CreateFeatureFlagRequest に従い、name、trafficType、オプションの description／tags／owners を指定します）。update は /fme/api/v4/feature-flags/{name} にマージパッチを送信します。archive／unarchive は /fme/api/v4/feature-flags/{name}/archive|unarchive にアクセスします（ArchiveUnarchiveRequest に従い、オプションの comment のみを指定します。title は指定できません）。kill／restore／reallocate は /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate にアクセスし、クエリパラメーターとして environment_id を指定します（FeatureFlagDefinitionActionRequest に従い、オプションの comment／title を指定します）。
• 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 の仕様はありませんでした。ネイティブの list では feature_flag_name が必須で、offset／limit（デフォルトは 100、最大 100）を使用します。environment_id は指定しません。delete と実行系操作では environment_id が必須です。kill／restore／reallocate は fme_feature_flag のものと同じ操作です。get／create／update の本文は従来モードと同じ（treatments、defaultTreatment、defaultRule、オプションの rules／baselineTreatment／trafficAllocation／comment）ですが、Harness ネイティブモードではオプションの title も指定できます。ネイティブの update は 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 の list_keys／add_keys／remove_keys を実行してください。
• fme_segment — ネイティブのみ（org_id＋project_id）。CRUDに対応します。list／get／update／delete には segment_type が必要です。値は STANDARD | LARGE | RULE_BASED です。作成時の本文には name、trafficType、segmentType が必要です。description、tags、owners は任意です。
• fme_segment_definition — ネイティブのみ。CRUDに加え、list_keys／add_keys／remove_keys の実行に対応します。更新できるのは説明のみです。キーが残っている場合、削除は hasDependents によって失敗します。
• fme_metric — Harnessネイティブのみ（レガシーの workspace_id はサポートされません）。list／get／create／update／delete は /fme/api/v4/metrics に接続されています（list の harness_list の size は limit にマッピングされます）。バックエンドの CreateMetricRequest では spread は任意（デフォルトは PER）ですが、create では必須です。これはMCP側のみのより厳格なコントラクトで、省略すると RATE メトリックの意味が予期せず変わるためです。update はJSON Merge Patchです。name／trafficType は不変で、受け付けられません。delete は完全なハード削除（アーカイブ／復元なし）であり、destructive に分類されます。
• fme_event_type — Harnessネイティブのみ（レガシーの workspace_id はサポートされません）。読み取り専用です。list／get は /fme/api/v4/event-types に接続されており、id はイベント名です。過去30日間にイベントがあったイベントタイプのみ表示されます。リクエスト元のワークスペースのトラフィックタイプのスコープ外にあるイベントタイプ、または30日を超えてイベントがないイベントタイプに対しては、get は404を返します。リストのフィルターは name（部分一致）、traffic_type（IDまたは名前）、offset／limit（harness_list の size は limit にマッピング）です。IDを推測するのではなく、fme_metric の baseEventTypes／filterEventType または event_type_ids フィルターで参照する前に、実際のイベントタイプIDを確認するために使用してください。
• 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 に分類されます。create／update では owners を任意で指定できます。各エントリーは {type: "USER", id or email} または {type: "GROUP", identifier} です。rule（ターゲティングルールの結果をスコープするラベル。省略して作成するとデフォルトは "default"、更新時に null を指定するとクリア）と、tags（[{name}]。更新時はリストを置き換え、null／[] でクリア）も create／update で任意指定できます。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 が必要）、一覧表示、取得、メタデータの更新、削除、および実行アクション（キル／復元／再割り当て／アーカイブ／アーカイブ解除）による完全なライフサイクル管理をサポートします。トラフィックタイプ ID の確認には fme_traffic_type を、アイデンティティ属性の作成／更新には 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 Engineering

Resource Type	List	Get	Create	Update	Delete	Execute Actions
chaos_experiment	x	x	x		x	run, stop
chaos_experiment_run		x
chaos_experiment_variable	x
chaos_component_variable		x
chaos_input_set	x	x	x	x	x
chaos_experiment_template	x	x			x	create_from_template, list_revisions, get_variables, get_yaml, compare_revisions
chaos_probe	x	x	x		x	enable, verify, get_manifest
chaos_probe_in_run	x
chaos_probe_template	x	x			x	get_variables
chaos_infrastructure	x
chaos_k8s_infrastructure	x	x	x			check_health
chaos_enabled_infrastructure	x
chaos_environment	x
chaos_hub	x	x	x	x	x
chaos_hub_fault	x
chaos_fault	x	x			x	get_variables, get_yaml
chaos_fault_template	x	x			x	list_revisions, get_variables, get_yaml, compare_revisions
chaos_fault_experiment_run	x
chaos_action	x	x	x		x	get_manifest
chaos_action_template	x	x			x	list_revisions, get_variables, compare_revisions
chaos_loadtest	x	x	x	x	x	run, stop
chaos_service	x	x	x	x	x	list_experiment_runs, list_load_tests
custom_service	x	x	x	x
chaos_application_map	x	x
discovered_agent	x
discovered_namespace	x
discovered_service	x
discovered_network_map	x
chaos_guard_condition	x	x			x
chaos_guard_rule	x	x			x	enable
chaos_recommendation	x	x
chaos_risk	x	x
chaos_dr_test	x		x
scanned_risk	x	x				occurrences, summary_by_service
chaos_risk_rule	x	x	x	x	x
chaos_risk_scan	x	x	x	x	x	retry, abort, report, report_download, heatmap, submit_findings

Cloud Cost Management (CCM)

Resource Type	List	Get	Create	Update	Delete	Execute Actions
cost_perspective	x	x	x	x	x
cost_breakdown	x
cost_timeseries	x
cost_summary	x	x
cost_recommendation	x	x				update_state, override_savings, create_jira_ticket, create_snow_ticket
cost_anomaly	x
cost_anomaly_summary		x
cost_category	x	x
cost_account_overview		x
cost_filter_value	x
cost_recommendation_stats		x
cost_recommendation_detail		x
cost_commitment		x
ai_budget	x	x	x	x	x
ai_budget_overview		x
ai_budget_consumption	x
ai_budget_override_request	x	x	x			approve, reject

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

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

リソースタイプ	一覧	取得	作成	更新	削除	アクションの実行
sei_metric	x
sei_productivity_metric		x
sei_dora_metric		x				metric に deployment_frequency、change_failure_rate、mttr、lead_time、または *_drilldown を渡します
sei_team	x	x
sei_team_detail	x					aspect に integrations、developers、integration_filters を渡します
sei_org_tree	x	x
sei_org_tree_detail	x	x				aspect に efficiency_profile、productivity_profile、business_alignment_profile、integrations、teams を渡します
sei_business_alignment	x	x				aspect に feature_metrics、feature_summary、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 を使用して、アカウント／組織／プロジェクトのスコープを指定できます。パイプライン、アーティファクト単体、gitoid など、単一のフリーテキストフィルターには search_term を使用します。追加の名前制約には filters.subject_name、サブジェクトのコンテンツダイジェストには filters.subject_digest を使用します。Get では gitoid_sha256 で検索し、org_id／project_id（リスト行から取得）が必要です。ダウンロード（harness_execute アクション download）は有効期限付きの download_url を返します。このリンクは必ずユーザーに提示してください。機能フラグ SCS_EVIDENCE_VAULT が必要です。

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

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

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
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" と、Pending、Approved、Rejected、Expired、Canceled などの明示的な status を指定して使用します。
• harness_execute を action="approve" と、必須の body.scope（CURRENT、ACCOUNT、ORG、PROJECT）を指定して使用します。CURRENT は免除の既存スコープで承認します。それ以外のスコープでは、内部的に STO の昇格エンドポイントを使用します。body.approver_id が省略された場合、サーバーは認証済みユーザーの値を自動入力します。body.comment は省略可能です。
• 免除を却下するには action="reject" を使用します。body.approver_id は省略された場合も自動入力されます。
• 個別の promote 実行アクションはありません。アカウント、組織、またはプロジェクトのスコープで承認する場合は、body.scope に CURRENT 以外の値を指定して action="approve" を使用してください。

アクセス制御

リソースタイプ	List	Get	Create	Update	Delete	実行アクション
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

ガバナンス

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

Deployment Freeze

Resource Type	List	Get	Create	Update	Delete	Execute Actions
freeze_window	x	x	x	x	x	toggle_status
global_freeze		x				manage

Service Overrides

Resource Type	List	Get	Create	Update	Delete	Execute Actions
service_override	x	x	x	x	x

Settings

Resource Type	List	Get	Create	Update	Delete	Execute Actions
setting	x

MCP Prompts

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	パイプライン実行のすべてのステップログを取得して要約します。include_logs: true, include_all_step_logs: true を指定して harness_diagnose を使い、すべてのステップのログを取得します。その後、ステップ名、ステータス、所要時間、発生した内容（ログに基づく要約）を表で提示します。ステップを省略しません。	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、リードタイム）を確認し、エリート／高／中／低に分類して、改善案を提示します	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（必須）、問題のフィルター（任意）
access-control-audit	最小権限を徹底するため、ユーザー権限、過剰な権限を持つアカウント、ロールの割り当てを監査します	projectId（任意）、orgId（任意）

Harness Code

プロンプト	説明	パラメーター
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 （アルファ）	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

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

デフォルトでは、46 個のツールセットのうち 42 個が有効になっています。4 個のツールセットはオプトイン方式で、デフォルトでは除外されています。

• ansible — Harness Ansible（インベントリ、プレイブック、ホスト、アクティビティ）。プロジェクト単位で適用され、多くのユーザーが必要としない概念を追加するため、オプトインです。
• autonomous_work — Development Harness（自律的な作業）。オプトインです。対象範囲についてはツールセットの説明をご覧ください。
• observability-evaluations — 本番環境のテレメトリーを定期評価するルール。デプロイ済みのスコアリングコントロールプレーンに依存するため、オプトインです。
• registries-v3 — Harness Artifact Registry v3（パッケージ、バージョン、ファイル、メタデータ、スキャン、ファイアウォール例外）。v3 の書き込み機能が導入されるまではオプトインです。これにより、エージェントが v1 のレジストリ／アーティファクトと v3 のパッケージ／バージョンを区別する必要がなくなります。

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

すべてのデフォルトに加えて、オプトインするツールセットを明示的に含めるには、+ プレフィックスを使います。

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

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

不要なツールセットを除外するには、- プレフィックスを使います。

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

+ と - の組み合わせ

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

明示的な許可リスト

プレフィックスを付けずにカンマ区切りで指定したリストを使うと、デフォルトがすべて置き換えられます。リストに記載したツールセットのみが有効になります。

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

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

ツールセット	リソースタイプ
platform	organization, project
pipelines	pipeline, pipeline_v1, pipeline_dynamic_execution, execution, execution_inputs, trigger, pipeline_summary, input_set, approval_instance
agents	agent, agent_run
services	service
environments	environment
connectors	connector, connector_catalogue, 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_service, custom_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan
ccm	cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment
sei	sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric
scs	scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom
evidence-vault	attestation
sto	security_issue, security_issue_filter, security_exemption, remediation_diff
dbops	database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline
autonomous_work (オプトイン)	work_item, work_item_resume, work_item_approve, work_timeline, work_budget, work_phase, work_phase_artifact, work_artifact, budget, budget_grant, budget_usage, work_class, work_trigger, capability, risk_evaluator, team, member, member_template, software_component, content_source_connector
access_control	user, user_group, service_account, role, role_assignment, resource_group, permission
governance	policy, policy_set, policy_evaluation
freeze	freeze_window, global_freeze
overrides	service_override
settings	setting
knowledge-graph	kg_queryable_type_summary, kg_grammar, hql_query
semantic-layer	kg_type, kg_related_type
ai-evals	eval_dataset, eval_dataset_item, evaluation, eval_run, eval_run_item, eval_run_by_eval, eval_metric, eval_metric_set, eval_metric_set_entry, eval_suite, eval_suite_evaluation, eval_suite_run, eval_target, eval_annotation, eval_analytics, eval_git_settings, eval_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

アーキテクチャ

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

仕組み

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

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

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

Elicitation

書き込みツール（harness_create、harness_update、harness_delete、harness_execute）は、操作のリスクに応じて確認を求めるためにMCP elicitationを使用します。対象はmedium_write、high_write、destructive操作のみです。リスクの低い作成・更新・読み取り（例：pipeline.create、pipeline.update、hql_query.run）はプロンプトを表示せずに実行されます。プロンプトが表示されると、ユーザーは実行予定の操作を確認して承認または拒否できます。これにより、実際にデータを変更したり処理を実行したりする操作に対して、人間が介在する確実な承認が行われます。

仕組み：

1. LLM がmedium_write以上のリスクを伴う書き込みツールを呼び出します（例：harness_delete、harness_execute pipeline.run）。リスクの低い作成・更新・読み取りでは、プロンプトは表示されません。
2. サーバーは操作の概要とconfirmチェックボックス（デフォルトでオン）を含む elicitation リクエストをクライアントに送信します。
3. ユーザーは詳細を確認し、Accept（confirmをオンにした状態）またはDecline / Cancelをクリックします。
4. confirm: trueで承認された場合、操作が実行されます。confirmがオフの状態で承認された場合、拒否された場合、またはキャンセルされた場合、操作はブロックされ、LLM にその旨が通知されます（明示的な拒否は最終判断であり、ツール呼び出しでconfirm: trueを指定しても覆りません）。

クライアントの対応状況：

クライアント	Elicitation の対応
Cursor	対応
VS Code (Copilot)	対応
Claude Desktop	未対応
Devin Desktop	未対応
MCP Inspector	対応

クライアントが対応していない場合の elicitation の動作は、操作のリスクによって異なります。

リスクレベル	クライアントの elicitation 対応	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が適用されます。ただし、elicitation のハンドシェイクを完了したクライアントからの明示的な拒否やキャンセルを覆すことはありません。

自律モード

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

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

関連スキル

Harness MCP サーバーは、一般的な Harness ワークフロー向けに設計された、すぐに使える Claude Code スキル（スラッシュコマンド）集である**Harness Skills**と相性よく連携します。この MCP サーバーと一緒にインストールすると、カスタムプロンプトを作成しなくても、/deploy、/rollback、/triage などの高度な自動化を利用できます。

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

症状	考えられる原因	対処方法
HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...	API キーがサポートされているアカウントスコープ形式（pat.<accountId>... または sat.<accountId>...）ではないため、アカウント ID を推定できません	HARNESS_ACCOUNT_ID を明示的に設定します
起動時の Unknown transport: "..."	サポートされていない CLI トランスポート引数です	stdio または http のみを使用します
起動時の Invalid HARNESS_TOOLSETS: ...	1 つ以上のツールセット名が認識されません	ツールセットのフィルタリングに記載された名前のみを使用します（完全一致）
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	クライアントが入力確認に対応していない、elicitInput が失敗した、または無効な承認結果が返されました	非対話型の自動化では confirm: true を指定して再試行するか、入力確認に対応したクライアントを使用します
テンプレートの作成／更新で 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 を設定します

License

MIT