Harness

官方

存取並與 Harness 平台資料互動，包括管道、儲存庫、日誌及成品註冊表。

GitHub

你可以用 Harness MCP 做什麼？

列出任何 Harness 資源 — 透過一次 harness_list 呼叫即可查詢管線、服務、功能旗標或成本資料，無需使用數百個特定端點的工具。
取得資源詳細資料 — 使用 harness_get 跨 224 種資源類型，擷取管線、環境或專案的完整組態。
動態探索組織與專案 — 詢問「跨所有專案」的失敗情況，代理程式會透過 harness_list(resource_type="project") 瀏覽帳戶階層。
建立與管理資源 — 透過整合的 harness_create（及相關）工具，佈建或更新管線、服務、環境與功能旗標。
執行預建的工作流程提示 — 觸發 34 個內建範本，用於建置與部署應用程式、偵錯失敗的管線、檢閱 DORA 指標，以及分類漏洞。
控制自主寫入風險 — 設定 HARNESS_AUTO_APPROVE_RISK，讓低風險操作自動核准，而風險較高的變更則需要確認。

文件

Harness MCP Server 2.0

一個 MCP（Model Context Protocol）伺服器，透過 11 個整合工具和 224 種資源類型，讓 AI 代理能完整存取 Harness.io 平台。

為什麼使用這個 MCP 伺服器

大多數 MCP 伺服器將每個 API 端點對應到一個工具。對於像 Harness 這樣廣泛的平台，這意味著 240+ 個工具——而隨著數量增加，LLM 在工具選擇上的表現會變差。上下文視窗會被 schema 塞滿，每個新端點都意味著新程式碼。

這個伺服器的建置方式不同：

11 個工具、224 種資源類型。 基於註冊表的派送系統將 harness_list、harness_get、harness_create 等路由到任何 Harness 資源——管線、服務、環境、組織、專案、功能旗標、成本資料等。LLM 只需從 11 個工具中選擇，而不是數百個。
完整的平台涵蓋範圍。 38 個預設工具集，涵蓋 CI/CD、GitOps、功能旗標、雲端成本管理、安全測試、混沌工程、資料庫 DevOps、內部開發者入口網站、軟體供應鏈、基礎設施即程式碼管理、治理、服務覆寫、知識圖譜等。當你需要庫存和 playbook 資料時，可選擇啟用 Ansible 涵蓋範圍。
開箱即用的多專案工作流程。 代理會動態探索組織和專案——無需硬編碼的環境變數。詢問「顯示所有專案中失敗的執行」時，代理就能瀏覽完整的帳戶階層。
34 個提示詞範本。 為常見工作流程預先建置的提示詞：端對端建置與部署應用程式、除錯失敗的管線、檢視 DORA 指標、分類漏洞、最佳化雲端成本、稽核存取控制、規劃功能旗標發布、審查 pull request、核准待處理的管線等。
隨處可用。 為本機用戶端（Claude Desktop、Cursor、Devin Desktop）提供 Stdio 傳輸，為遠端/共享部署提供 HTTP 傳輸，並支援 Docker 和 Kubernetes。
零設定啟動。 只需提供 Harness API 金鑰。帳戶 ID 會自動從 PAT 和 SAT 權杖中擷取，組織/專案預設值為選用，工具集篩選可讓你只暴露需要的部分。
設計上可擴充。 新增 Harness 資源只需加入宣告式資料檔——無需註冊新工具、無需變更 schema、無需更新提示詞。

先決條件

在安裝或執行伺服器之前，你需要一個 Harness API 金鑰：

登入你的 Harness 帳戶
前往 我的個人資料 → API 金鑰 → + 新增 API 金鑰
在 API 金鑰下建立新的權杖——這會產生格式為 <prefix>.<accountId>.<tokenId>.<secret> 的 PAT 或 SAT
將權杖儲存在安全的地方——下一步你會需要它

如需詳細說明，請參閱 Harness API 快速入門。

快速入門

選項 0：託管的 Harness MCP

如果你的 Harness 帳戶已啟用託管 MCP 服務，支援遠端 MCP 伺服器的用戶端可以直接連線到受管端點，而無需在本機執行伺服器。

重要： 託管 MCP 服務使用 Harness Platform OAuth，而非 HARNESS_API_KEY。此外，端點必須先由 Harness 支援團隊 依帳戶啟用/設定後才能使用。

請參閱託管的 Harness MCP 取得設定範例。

選項 1：npx（建議）

無需安裝——直接執行：

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

或在你的 AI 用戶端中設定 API 金鑰（請參閱下方的用戶端設定）。

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

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

注意： 帳戶 ID 會自動從 PAT 和 SAT 權杖（pat.<accountId>... 或 sat.<accountId>...）中擷取，因此 HARNESS_ACCOUNT_ID 僅在 API 金鑰未內嵌帳戶區段時才需要。

選項 2：全域安裝

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

選項 3：從原始碼建置

用於開發或自訂：

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

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

Anthropic MCP Directory 套件

MCPB 套件 manifest 位於 [mcp-directory/](mcp-directory/)，套件圖示則在儲存庫根目錄的 [icon.png](icon.png) 追蹤。在 pnpm build 之後將 mcp-directory/manifest.json 複製到套件根目錄，使產生的封存檔包含根層級的 manifest.json、icon.png、build/、package.json 和正式環境的 node_modules/。

為保持封存檔小巧，請從暫存目錄建置 MCPB 套件：

pnpm prepare:mcpb

暫存的套件會寫入 dist/mcpb/，並使用 npm 的扁平佈局安裝正式環境相依套件。

CLI 使用方式

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

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

若未指定，傳輸預設為 stdio。遠端/共享部署請使用 http。

HTTP 傳輸

在 HTTP 模式下執行時，伺服器會暴露：

端點	方法	說明
`/mcp`	`POST`	MCP JSON-RPC 端點（initialize + session 請求）
`/mcp`	`GET`	伺服器發起訊息的 SSE 串流（進度、引導）
`/mcp`	`DELETE`	終止作用中的 MCP session
`/mcp`	`OPTIONS`	CORS 預檢
`/health`	`GET`	健康檢查——回傳 `{ "status": "ok", "sessions": <count> }`

HTTP 傳輸以基於 session 的模式執行。新的 MCP session 會在 initialize 時建立，伺服器會回傳 mcp-session-id 標頭，該 session 的後續請求必須包含相同的標頭。

HTTP 模式下的操作限制：

任何共享或可遠端存取的部署都應設定 HARNESS_MCP_AUTH_TOKEN。設定後，每個對 /mcp 的 POST、GET 和 DELETE 請求都必須包含 Authorization: Bearer <token>。
非 loopback 綁定預設需要 HARNESS_MCP_AUTH_TOKEN。若仍要在非 loopback 介面上以未驗證方式執行，請明確設定 HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true。
沒有 mcp-session-id 的 POST /mcp 必須是 initialize 請求。
現有 session 的 POST /mcp、GET /mcp 和 DELETE /mcp 需要 mcp-session-id 標頭。
GET /mcp 用於 SSE 通知（進度更新和引導提示）。
閒置 session 在沒有請求或 SSE 串流作用中 MCP_SESSION_TTL_MS 毫秒後會被回收（預設 1800000，即 30 分鐘）。
GET /health 是唯一的非 MCP 端點。
請求主體大小由 HARNESS_MAX_BODY_SIZE_MB 限制（預設 10 MB）。
在 initialize 請求上設定 x-harness-pipeline-version: 0 或 1，以為該 HTTP session 選擇 V0 或 V1 管線資源。
在 initialize 請求上設定 x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all，以選擇更嚴格的每 session 自動核准門檻。伺服器會將此值上限設為部署層級的 HARNESS_AUTO_APPROVE_RISK，因此 session 可以降低但不能提高設定的核准上限。

多使用者模式

在每個用戶端以不同 Harness 使用者身分驗證的共享 HTTP 部署中，設定 HARNESS_MCP_MODE=multi-user。在此模式下：

伺服器設定中不得設定 HARNESS_API_KEY——伺服器不持有任何 Harness 憑證。
每個 session 必須在 initialize 請求上提供 x-harness-api-key。僅當 API 金鑰未內嵌帳戶區段時才需要 x-harness-account-id。
Session 也可以提供 x-harness-org 和 x-harness-project 標頭，以設定該 session 的預設範圍。
Harness API 金鑰會流經該 session 的每個 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-rebinding 防護的 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 端點。當你想要共享的遠端 MCP 端點，而不是執行 npx harness-mcp-v2 或自行託管 HTTP 傳輸時，這會很有用。

重要： 託管 MCP 驗證使用 Harness Platform OAuth。它不使用用戶端設定中的 HARNESS_API_KEY。託管 MCP 的可用性依 Harness 帳戶設定，因此你需要與 Harness 支援團隊 合作，在使用前啟用/設定該選項。

託管端點 https://mcp.harness.io/mcp 是受管服務。Claude、Cursor 或 Cowork 中的用戶端 MCP 設定無法覆寫其路由到的 Harness 環境。對於 Harness0 或其他私有 Harness SaaS 環境，請要求 Harness 支援團隊為該環境啟用/設定託管 MCP，或執行本機/自架伺服器並將 HARNESS_BASE_URL 設定為目標 Harness 主機。

託管 MCP 範例：

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

同時包含託管和本機項目的範例：

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

疑難排解 npx ENOENT 或 node: No such file or directory

這是用戶端程序啟動失敗，而非 Harness 驗證失敗。MCP 伺服器尚未啟動，因此變更 HARNESS_API_KEY 不會影響 spawn npx ENOENT。

GUI 應用程式（Cursor、Claude Desktop、Devin Desktop、VS Code）不一定會繼承你 shell 的 PATH，因此在重新載入設定後，它們可能找不到 npx 或 node。請使用絕對路徑並在 env 區塊中明確設定 PATH 來修正此問題：
{
  "mcpServers": {
    "harness": {
      "command": "/absolute/path/to/npx",
      "args": ["-y", "harness-mcp-v2"],
      "env": {
        "HARNESS_API_KEY": "pat.xxx.xxx.xxx",
        "PATH": "/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}
在終端機中使用 which npx 和 which node 找出你的路徑，然後確保包含 node 的目錄已包含在上方的 PATH 值中。常見位置：

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

nvm： ~/.nvm/versions/node/v20.x.x/bin/npx（執行 nvm which current 找出確切路徑）

系統 Node： /usr/local/bin/npx

Claude Desktop（`claude_desktop_config.json`）

npx（零安裝）

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

node（本機安裝）

npm install -g harness-mcp-v2

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

Claude Code（透過 `claude mcp add`）

npx（零安裝）

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

node（本機安裝）

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

然後在環境或 .env 檔案中設定 HARNESS_API_KEY。

Cursor（`.cursor/mcp.json`）

npx（零安裝，建議用於本機 Cursor 設定）

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

在終端機中執行 which npx，並將該完整路徑用於 command；將 which node 的目錄放在 PATH 的前面。

node（本機安裝）

npm install -g harness-mcp-v2

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

在 npm install -g harness-mcp-v2 之後執行 which harness-mcp-v2，並將該完整路徑用於 command；將 which node 的目錄放在 PATH 的前面。

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

npx（零安裝）

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

node（本機安裝）

npm install -g harness-mcp-v2

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

使用從原始碼建置的本機版本？

將命令替換為你建置之 index.js 的路徑：

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

MCP Gateway

Harness MCP 伺服器與 MCP Gateway 完全相容——這些反向代理可在多個 MCP 伺服器之間提供集中式驗證、治理、工具路由和可觀測性。由於伺服器透過 stdio 和 HTTP 兩種傳輸方式實作標準 MCP 協定，因此可在任何符合 MCP 規範的 gateway 後方運作，無需修改任何程式碼。

為什麼要使用 gateway？

集中式憑證管理 — 代理程式設定中不需要 API 金鑰
跨團隊所有工具呼叫的治理與稽核日誌
代理程式只需單一端點，而非連接到 N 個 MCP 伺服器的 N 條連線
存取控制 — 限制哪些團隊可以使用哪些工具

Docker MCP Gateway

在您的 Docker MCP Gateway 設定中註冊此伺服器：

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

Portkey

將 Harness MCP 伺服器新增至您的 Portkey MCP Gateway，以獲得企業級治理、成本追蹤和多 LLM 路由：

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

LiteLLM

新增至您的 LiteLLM proxy config：

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 gateway 基礎架構公開 Harness MCP 伺服器。

其他 Gateway

任何支援 MCP 規範的 gateway（Microsoft MCP Gateway、IBM ContextForge、Cloudflare Workers 等）都可以代理此伺服器。對於基於 stdio 的 gateway，請使用預設傳輸方式。對於基於 HTTP 的 gateway，請使用 http 傳輸方式啟動伺服器，並將 gateway 指向 /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

容器預設以 HTTP 模式在連接埠 3000 上執行，並內建健康檢查功能。

Kubernetes

使用提供的 manifest 檔案部署至 Kubernetes 叢集：

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

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

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

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

此部署會執行 2 個複本，具備就緒/存活探測、資源限制和非 root 安全內容。Service 在內部公開連接埠 80（目標為容器連接埠 3000）。

設定

如果專案根目錄中存在 .env 檔案，伺服器會自動從中載入環境變數。將 .env.example 複製為 .env 並填入您的值。環境變數也可以透過您的 shell 或 MCP 用戶端設定來設定。

變數	必填	預設值	說明
`HARNESS_MCP_MODE`	否	`single-user`	部署模式：`single-user`（設定檔中的 API 金鑰，用於所有工作階段）或 `multi-user`（僅限 HTTP，透過 `x-harness-api-key` 與選用的 `x-harness-account-id` 標頭提供每工作階段憑證）
`HARNESS_API_KEY`	是*	--	Harness 個人存取權杖或服務帳戶權杖。在 `single-user` 模式下為必填。在 `multi-user` 模式下不得設定
`HARNESS_ACCOUNT_ID`	否	(來自 PAT/SAT)	Harness 帳戶識別碼。在單一使用者模式下會從 PAT/SAT 權杖自動擷取；當 API 金鑰未內嵌帳戶識別碼時，多使用者工作階段可透過 `x-harness-account-id` 提供自己的帳戶識別碼
`HARNESS_BASE_URL`	否	`https://app.harness.io`	適用於本機 stdio 或自架 HTTP 部署的 Harness API/UI 基礎 URL。自行執行伺服器時，請將其設定為 `https://harness0.harness.io` 等環境。此設定不影響受管理的 `https://mcp.harness.io/mcp` 託管端點
`HARNESS_FME_API_KEY`	否	--	用於 `fme_` 資源的選用單一使用者/自架 FME/Split 管理員憑證。這可以是舊版 Split 管理員金鑰或具 FME 權限的 Harness PAT/SAT。FME 呼叫會直接送往 `api.split.io`，因此 Harness 平台 API 的託管 OAuth/服務路由憑證無法驗證這些請求。在 `multi-user` 模式下不得設定；FME 必須使用每個工作階段的 `x-harness-api-key` 憑證。若未設定，FME 會為自架工作階段回退至非預留位置的 `HARNESS_API_KEY`
`HARNESS_FME_BASE_URL`	否	`https://api.split.io`	由 `fme_` 資源使用的 Split/FME Admin API 基礎 URL。HTTP URL 在本機開發時需要 `HARNESS_ALLOW_HTTP=true`
`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`	封鎖所有變更操作（建立、更新、刪除、執行）。僅允許 list 和 get。適用於共用/示範環境
`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`	（Alpha） Pipeline YAML 版本。`0` 載入 `pipeline` 資源類型並排除 `pipeline_v1`；`1` 載入 `pipeline_v1` 並排除 `pipeline`。HTTP 工作階段可在初始化時使用 `x-harness-pipeline-version: 0` 或 `1` 覆寫此設定
`HARNESS_MCP_ALLOWED_HOSTS`	否	--	HTTP 傳輸 Host 標頭驗證允許的主機名稱（以逗號分隔）。`mcp.harness.io` 預設允許用於 localhost 繫結；請在此處新增代理/自訂網域
`HARNESS_MCP_AUTH_TOKEN`	否	--	設定後，`/mcp` HTTP 路由需要 Bearer 權杖。當 HTTP 傳輸繫結至非 loopback 主機時，預設為必填
`HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP`	否	`false`	明確允許在非 loopback 繫結上使用未驗證的 HTTP 傳輸。僅可在另一個已驗證的控制項後方使用
`HARNESS_MCP_TRUST_PROXY`	否	`0`	用戶端 IP 解析時信任的反向代理/負載平衡器跳數（Express `trust proxy`）。請設定為伺服器前方的代理數量，以便每個 IP 的速率限制以真實用戶端為鍵，而非代理 socket 對端
`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 稽核 spans
`HARNESS_SEARCH_PROVIDER`	否	`local`	語意搜尋後端：`local`（程序內 ONNX 嵌入，預設）、`remote`（透過 HTTP 的外部搜尋服務，多使用者模式必備）或 `none`（停用語意搜尋，僅回退至關鍵字 scatter-gather）。在氣隙環境或不想在啟動時載入模型時，請使用 `none`
`HARNESS_SEARCH_SERVICE_URL`	否	--	使用 `HARNESS_SEARCH_PROVIDER=remote` 時遠端搜尋服務的基礎 URL（例如 `http://search-svc:8080`）。使用 `remote` 提供者時為必填
`HARNESS_SEARCH_SERVICE_HEADERS`	否	--	隨每個請求傳送至遠端搜尋服務的標頭 JSON 物件。支援任何驗證方案：`{"Authorization":"Bearer tok"}`、`{"x-api-key":"key"}` 或多個內部服務對服務標頭
`HARNESS_HF_CACHE_DIR`	否	`/tmp/hf-cache`	用於 `local` 搜尋提供者所使用的 `@huggingface/transformers` 模型快取的目錄。Docker 映像已将模型预先嵌入 `/app/.cache/hf`，以避免執行時期下載。在生產環境部署中，請設定為持久化磁碟區路徑
`HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY`	否	`3`	`harness_diagnose` 在擷取失敗步驟的日誌時所發出的最大並行日誌 blob 下載數。僅在診斷延遲主要由日誌擷取的實際耗時主導，且 Pod 具有記憶體餘裕時才需調高

語意搜尋

harness_search 使用語意路由來縮小 scatter-gather API 呼叫的範圍，再向 Harness 展開。提供三種搜尋提供者：

提供者	使用時機
`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

在本機測試遠端提供者，使用隨附的 stub 服務（無外部相依）：

# 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（stub-search-service.py）實作了與正式環境搜尋服務相同的 /v1/health、/v1/ingest 和 /v1/search 契約。它使用簡單的 bag-of-chars 嵌入，因此不需要下載模型——結果在語意上合理，但非生產級品質。

HTTPS 強制執行

HARNESS_BASE_URL 預設必須使用 HTTPS。如果您設定了非 HTTPS 的 URL（例如 http://localhost:8080），伺服器將拒絕啟動並顯示：

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

稽核日誌

當設定稽核 sink 時，所有由 registry 分派的 Harness API 操作（list、get、create、update、delete 和 execute）都會發出結構化稽核事件。變更事件在存在確認上下文時，會包含 elicitation 或自動核准所使用的確認路徑；讀取事件目前省略確認中繼資料。繞過 registry 的本機中繼資料與 schema 探索工具（例如 harness_describe 和 harness_schema）不屬於此稽核串流。預設會註冊 stderr sink，但它會經過一般 logger 並遵循 LOG_LEVEL；請設定檔案或 webhook sink 以進行持久化稽核收集：

HARNESS_AUDIT_FILE 以換行分隔的 JSON 事件附加，供本機收集。
HARNESS_AUDIT_WEBHOOK_URL 將 { "events": [...] } 批次發布到 HTTPS webhook，可選擇搭配 HARNESS_AUDIT_WEBHOOK_TOKEN。失敗的批次會以有限容量重新排入佇列，最終以警告方式丟棄，而不會阻擋工具執行。
OTEL_EXPORTER_OTLP_ENDPOINT 在安裝選用的 OpenTelemetry peer 相依套件時啟用稽核 spans。當已有註冊的 tracer provider 時，sink 會重複使用；否則會自行啟動獨立的 OTLP exporter。

每個事件都包含工具名稱、資源類型、操作、識別碼、時間戳記、風險、結果、HTTP 方法/路徑、持續時間，以及適用的確認方法。稽核 sink 是盡力而為的遙測；傳遞問題會被記錄，且絕不會重播或變更底層的 Harness API 操作。有關 OTel 設定詳細資訊和 span 屬性，請參閱 specs/005-otel-audit-sink.md。

工具參考

伺服器提供 11 個 MCP 工具。大多數 API 工具接受 org_id 和 project_id 作為選用覆寫——如果省略，則會回退到 HARNESS_ORG 和 HARNESS_PROJECT。harness_describe 僅為本機中繼資料，不使用 org/project 範圍。

URL 支援： 大多數面向 API 的工具接受 url 參數——貼上 Harness UI URL，伺服器會自動擷取 org、project、資源類型、資源 ID、pipeline ID 和執行 ID。harness_describe 不接受 url。

範圍支援： 具有 account/org/project 變體的資源類型會在 harness_describe 中公開 supportedScopes。當您需要特定層級時，請傳入 resource_scope：

resource_scope: "account" 僅傳送 accountIdentifier。
resource_scope: "org" 傳送 accountIdentifier 和 orgIdentifier。
resource_scope: "project" 傳送 account、org 和 project 識別碼。

目前的多範圍資源包括 connector、service、environment、infrastructure、secret、file_store 和 template。如果省略 resource_scope，registry 會使用資源的預設範圍和已設定的預設值，但標記為選用範圍的資源可能會省略 org/project，除非明確傳入。當路徑包含 account 層級或 project 層級上下文時，Harness URL 也可以自動設定範圍。

結構化輸出： 每個工具都宣告一個 MCP outputSchema。harness_list 會將類似清單的 Harness 回應正規化為物件形狀的結構化內容，以便嚴格的用戶端可以驗證它：頂層陣列變成 { "items": [...], "total": <count>, "page": <page> }，常見的包裝鍵（例如 content、data、body、objects 或 features）會在需要時提升到 items。文字回應仍包含回傳給所有用戶端的精簡 JSON 負載。

工具	說明
`harness_describe`	探索可用的資源類型、操作和欄位。不進行 API 呼叫——回傳本機 registry 中繼資料。
`harness_schema`	取得用於建立/更新資源的確切 YAML/JSON Schema 定義和範例。Pipeline/template schemas 已隨附；connector、environment、service、secret 和 infrastructure schemas 是從隨附快照或 NG `/yaml-schema` 取得的範圍感知實體 schemas。支援透過 `path` 進行深入探查。
`harness_list`	列出指定類型的資源，支援篩選、搜尋和分頁。
`harness_get`	依識別碼取得單一資源。
`harness_create`	建立新資源。支援內聯和遠端（Git 支援）pipeline。透過 elicitation 提示使用者確認。
`harness_update`	更新現有資源。支援內聯和遠端（Git 支援）pipeline。透過 elicitation 提示使用者確認。
`harness_delete`	刪除資源。透過 elicitation 提示使用者確認。具破壞性。
`harness_execute`	對資源執行操作（執行/重試 pipeline、從 Git 匯入 pipeline、切換旗標、同步應用程式）。透過 elicitation 提示使用者確認。對於 pipeline 執行，請使用下方的 runtime-input 工作流程（支援 `branch`/`tag`/`pr_number`/`commit_sha` 速記展開）。
`harness_search`	使用單一查詢跨 Harness 資源類型搜尋。使用語意路由（本機 `all-MiniLM-L6-v2` ONNX 嵌入，384 維）從啟動時索引的 `knowledge` 語料庫預測相關資源類型——通常在 scatter-gather 前從約 163 種類型縮小到 1–8 種。當語意信心較低時，會回退到完整的關鍵字 scatter-gather。當路由觸發時，回應會包含 `semantic_routed` 和 `types_skipped`。請參閱 `docs/search-guidelines.md` 了解如何讓新的資源類型可被探索。
`harness_diagnose`	診斷 `pipeline`、`connector`、`delegate` 和 `gitops_application` 資源（別名：`execution` -> `pipeline`、`gitops_app` -> `gitops_application`）。對於 pipeline，回傳 stage/step 時間和失敗詳細資訊；對於 connector/delegate/GitOps 應用程式，回傳針對性的健康狀態和疑難排解訊號。
`harness_status`	取得即時專案健康狀態儀表板——最近的執行、失敗率和深層連結。

Schema 查詢工作流程

在建立或更新 YAML 支援的資源之前，請使用 harness_schema，以便代理程式可以複製確切的欄位名稱和約束，而不是從文字描述中猜測。

隨附的 schemas 包括 pipeline、template、trigger、pipeline_v1、template_v1、inputSet_v1、overlayInputSet_v1 和 agent-pipeline。
實體 schemas 包括 connector、environment、service、secret 和 infrastructure。它們是範圍感知的（account、org 或 project），當所選範圍需要時，需要 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 schemas 變更時，維護者可以使用 pnpm sync-entity-schemas 重新整理隨附的實體快照。

工具範例

探索可用的資源：

{ "resource_type": "pipeline" }

列出帳戶中的組織：

{ "resource_type": "organization" }

列出組織中的專案：

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

列出專案中的 pipeline：

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

取得特定服務：

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

執行 pipeline：

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

診斷 connector 連線：

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

診斷 delegate 健康狀態：

{ "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 的最新執行報告：

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

依遷移類型篩選資料庫 schemas：

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

列出 schema 的資料庫實例：

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

取得 Schema 與實例的解析後 LLM 撰寫管線（resolved LLM authoring pipeline）：

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

列出某個 Schema 實例的快照物件名稱（例如資料表）：

{
  "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"]
  }
}

管線執行工作流程（建議）

請使用此順序以減少執行階段的輸入錯誤：

探索必要的執行時期輸入

harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
回傳的範本會顯示需要數值的 <+input> 佔位符。

選擇輸入策略

簡單變數： 傳入平坦的鍵值對 inputs（例如 {"branch":"main","env":"prod"}）。
複雜／結構化輸入： 使用 input_set_ids（CI 程式碼庫／建置區塊與巢狀範本輸入最適合以此方式處理）。

CI 程式碼庫速記鍵（僅限管線執行）：

速記鍵	展開後的結構
`branch`	`build.type=branch`, `build.spec.branch=<value>`
`tag`	`build.type=tag`, `build.spec.tag=<value>`
`pr_number`	`build.type=PR`, `build.spec.number=<value>`
`commit_sha`	`build.type=commitSha`, `build.spec.commitSha=<value>`

限制： 當 inputs.build 已存在時，會略過速記展開（明確的 build 優先）。

執行執行序

harness_execute(resource_type="pipeline", action="run", resource_id="<pipeline_id>", ...)

對於以 Git 為後端且其 YAML 應從非預設分支載入的管線，請傳入 params.pipeline_branch（以 pipelineBranchName 傳送至 Harness）：

{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "deploy_app",
  "params": { "pipeline_branch": "feature/new-stage" },
  "inputs": { "branch": "main" },
  "wait": true
}

選用：合併兩者

使用 input_set_ids 作為基礎形狀，並使用 inputs 進行簡單覆寫。

如果必要欄位無法解析，工具會回傳預檢錯誤，其中包含預期的鍵與建議的輸入集。您可以使用 harness_describe(resource_type="pipeline")（executeActions.run.inputShorthands）檢查可用的速記對應。

動態管線執行

當代理程式或外部系統在執行時期產生完整的 v0 管線 YAML，並需要針對現有的 Harness 管線外殼執行時，請使用 pipeline_dynamic_execution.run。這不是一般 pipeline.run 的替代方案：已儲存的 v0 管線必須已存在，帳戶層級與管線層級的 Allow Dynamic Execution 都必須啟用，而且呼叫者需要具備該管線的 Edit 與 Execute 權限。

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

限制：

body 必須是含有 yaml 欄位的物件。公開的 harness_execute schema 會拒絕原始字串內文。
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 Input Forensics）

在執行後使用 execution_inputs，以檢查產生特定執行序的合併輸入 YAML。當失敗取決於輸入集合併、Git 後端輸入集分支，或難以僅從執行頁面重建的觸發器／執行時期數值時，此功能特別有用。

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

get 回應會投影至：

executionId - 來自 resource_id 的計畫執行 ID。
inputSetYaml - 用於該執行的合併執行時期輸入 YAML，或 null。
inputSetTemplateYaml - 執行時期的輸入範本，或 null。
resolvedYaml - 當 resolve_expressions=true 時的運算式解析 YAML，否則通常為 null。
inputSetDetails - 以 { identifier, name } 配對形式呈現的貢獻已儲存輸入集。
inputSetBranchName - Git 後端輸入集的來源分支，或 null。

execution_inputs 僅供取得且為唯讀風險。如果省略 resolve_expressions，伺服器會省略 API 查詢參數，而 Harness 會使用其預設的 UNKNOWN 解析模式。

管線執行等待模式（Pipeline Execute Wait Mode）

對於 pipeline.run、pipeline.retry 與 pipeline_v1.run，請傳入 wait: true，讓伺服器輪詢直到執行序達到終止狀態。這可讓管線啟動與狀態檢查在單一工具呼叫中完成，而無需要求用戶端或 LLM 自行執行輪詢迴圈。

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

等待模式行為：

預設逾時為 600 秒；允許範圍為 10 秒至 7200 秒。
初始輪詢間隔預設為 3 秒，以 1.5 倍退避，並上限為 30 秒。
無論成功或失敗，回應都會包含諸如 execution_id、execution_status、execution_terminal、execution_elapsed_ms 與 execution_poll_count 等欄位。
如果逾時觸發，原始觸發器仍然成功；回應會包含 execution_timed_out: true 與 _wait.hint，並附上最後觀察到的狀態。
如果觸發器成功後輪詢失敗，回應會包含 _wait.error 與重新檢查提示。除非您已確認第一次執行並未執行中，否則請勿盲目重新執行管線。
失敗的終止狀態包括指向 harness_diagnose(resource_type="execution", options={execution_id: "..."}) 的 _diagnose_hint。

請 AI DevOps 代理程式建立管線：

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

透過自然語言更新服務：

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

管線儲存模式

Harness 管線可以透過三種方式儲存：

模式	說明	使用時機
Inline（內嵌）	管線 YAML 儲存在 Harness 中	預設。設定最簡單，無需 Git。
Remote（External Git）	管線 YAML 儲存在 GitHub、GitLab、Bitbucket 等平台中	使用以 Git 為後端的 pipeline-as-code 搭配外部供應商的團隊。
Remote（Harness Code）	管線 YAML 儲存在 Harness Code 儲存庫中	使用 Harness 內建 Git 託管服務的團隊。

建立內嵌管線（預設）：

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

建立遠端管線（External Git — 例如 GitHub）：

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

建立遠端管線（Harness Code — 無需連接器）：

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

更新遠端管線：

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

從外部 Git 儲存庫匯入管線：

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

從 Harness Code 儲存庫匯入管線：

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

建立連接器：

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

刪除觸發器：

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

列出管線的輸入集：

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

取得特定輸入集：

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

建立輸入集：

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

更新輸入集：

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

刪除輸入集：

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

資源類型

224 種資源類型，組織於 38 個工具集中。每種資源類型支援 CRUD 操作的子集，並提供選用的執行動作。

平台（Platform）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`organization`	x	x	x	x	x
`project`	x	x	x	x	x

管線（Pipelines）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`pipeline`	x	x	x	x	x	`run`, `retry`
`pipeline_v1` （Alpha）	x	x	x	x	x	`run`
`pipeline_dynamic_execution`						`run`
`execution`	x	x				`interrupt`
`execution_inputs`		x
`trigger`	x	x	x	x	x
`pipeline_summary`		x
`input_set`	x	x	x	x	x
`runtime_input_template`		x
`approval_instance`	x					`approve`, `reject`

啟動時只會載入一種管線 YAML 資源類型。依預設，HARNESS_PIPELINE_VERSION=0 會暴露 pipeline 並隱藏 pipeline_v1；設定 HARNESS_PIPELINE_VERSION=1 可暴露 pipeline_v1 並隱藏 pipeline。在 HTTP 模式下，請在 initialize 請求中包含 x-harness-pipeline-version: 0 或 1，以在該工作階段中選擇版本。

AI 代理程式（AI Agents）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`agent`	x	x	x	x	x
`agent_run`	x

服務（Services）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`service`	x	x	x	x	x

環境（Environments）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`environment`	x	x	x	x	x	`move_configs`

連接器（Connectors）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`connector`	x	x	x	x	x	`test_connection`
`connector_catalogue`	x

基礎設施（Infrastructure）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`infrastructure`	x	x	x	x	x	`move_configs`

機密（Secrets）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`secret`	x	x

執行日誌（Execution Logs）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`execution_log`		x

稽核軌跡（Audit Trail）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`audit_event`	x	x

代理程式（Delegates）

資源類型	List	Get	Create	Update	Delete	Execute Actions
`delegate`	x
`delegate_token`	x	x	x		x	`revoke`, `get_delegates`

程式碼儲存庫（Code Repositories）

資源類型	列表	取得	建立	更新	刪除	執行動作
`repository`	x	x	x	x
`branch`	x	x	x		x
`commit`	x	x	x			`diff`, `diff_stats`
`file_content`		x				`blame`
`tag`	x		x		x
`repo_rule`	x	x
`space_rule`	x	x

commit 建立會直接透過 Harness Code API 提交一或多個檔案動作，無需複製儲存庫。傳入 body.title、body.branch 與 body.actions；每個動作是 CREATE、UPDATE、DELETE 或 MOVE，且 UPDATE 需要目前的 blob SHA。

Artifact Registries

資源類型	列表	取得
`registry`	x	x
`artifact`	x
`artifact_version`	x
`artifact_file`	x

File Store

資源類型	列表	取得	建立	更新	刪除	執行動作
`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"})

Multipart 內文限制：

建立/更新接受 JSON body，然後將其轉換為 multipart/form-data 以用於 /ng/api/file-store。
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）或完整的 FileStoreNode body，包含 identifier、name 與 type: "FOLDER"。完整內文使用 Harness camelCase parentIdentifier；簡寫可使用 params.parent_identifier。

Templates

資源類型	列表	取得	建立	更新	刪除	執行動作
`template`	x	x	x	x	x

模板操作使用 Harness Template 服務路徑（/template/api/templates...）。建立與更新需要在 body.template_yaml 或 body.yaml 中提供完整的模板 YAML 字串；version_label 針對特定版本進行更新/刪除，而刪除時若省略 version_label 則刪除所有版本。

Dashboards

資源類型	列表	取得	建立	更新	刪除	執行動作
`dashboard`	x	x
`dashboard_data`		x

Database 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_workspace 建立/更新僅回傳 { policy_evaluation } — 請接著使用 harness_get 擷取工作區。iacm_variable_set 建立/更新回傳 VariableSet 資源本身。變數集更新是 HTTP PUT 且集合為完全取代 — 務必先 harness_get，然後 PUT 完整的期望內文（更新時 terraform_variables / environment_variables 為必要；省略/清空會清除連接器與變數檔）。寫入是 medium_write 且需要確認（徵詢或 confirm: true）。

變數集 RBAC（iac_variableset_*）目前在 Harness 為實驗性功能 — 在 iac-server 啟用強制執行前，存取檢查一律允許。MCP 仍會原封不動地轉送呼叫者的 PAT/SAT。

資源類型	列表	取得	建立	更新
`iacm_workspace`	x	x	x	x
`iacm_variable_set`	x	x	x	x
`iacm_resource`	x
`iacm_module`	x	x
`iacm_workspace_costs`	x
`iacm_activity_resource_change`	x

典型工作流程：

harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") 找到工作區。
對 iacm_workspace 使用 harness_create / harness_update，從頭建立或從範本（associated_template）建立，或更新現有工作區 — 回應僅為 { policy_evaluation }。
harness_get(resource_type="iacm_workspace", workspace_id="...") 擷取已建立/更新的工作區。
對 iacm_variable_set 使用 harness_list / harness_create / harness_update（可搭配 resource_scope）取得可重複使用的 Terraform/env 變數集 — 回應是 VariableSet 資源。
harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") 檢查 Terraform 資源、輸出與資料來源。
harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") 檢視每次執行的成本項目。
harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") 檢查 plan、apply 或 destroy 活動的變更前後資源差異。

IaCM 列表回應僅將 page_count 公開為目前頁面的計數（iacm_variable_set 除外，它不分頁）。當 has_more 為 true 時，持續要求下一頁（1 為基礎）並加總頁面計數，若需要總數。

Internal Developer Portal (IDP)

資源類型	列表	取得	執行動作
`idp_entity`	x	x
`scorecard`	x	x
`scorecard_check`	x	x
`scorecard_stats`		x
`scorecard_check_stats`		x
`idp_score`	x	x
`idp_workflow`	x		`execute`
`idp_tech_doc`	x

Pull Requests

資源類型	列表	取得	建立	更新	執行動作
`pull_request`	x	x	x	x	`close`, `merge`
`pr_reviewer`	x		x		`submit_review`
`pr_comment`	x		x
`pr_check`	x
`pr_activity`	x

對明確的關閉操作使用 harness_execute(resource_type="pull_request", action="close", ...)。harness_update 也接受 body.state（open 或 closed），並將狀態變更路由至專屬的 Harness Code PR 狀態端點；請在另一個更新呼叫中傳送標題/描述編輯。

Feature Flags

資源類型	列表	取得	建立	更新	刪除	執行動作
`fme_workspace`	x
`fme_environment`	x
`fme_feature_flag`	x	x	x	x	x	`kill`, `restore`, `archive`, `unarchive`
`fme_feature_flag_definition`		x	x	x
`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（Split.io）資源 — fme_* 資源使用 Split.io API（api.split.io），並以工作區 ID（而非組織／專案）作為範圍依據。在單一使用者／自架模式下，驗證使用來自 HARNESS_FME_API_KEY 的 Bearer token，並在無法取得時回退至非佔位符的 HARNESS_API_KEY。HARNESS_FME_API_KEY 可以是舊版的 Split admin key，或是具 FME 權限的 Harness PAT/SAT，但在 multi-user 模式下會被拒絕，因此共享部署無法覆寫各工作階段使用者的憑證。Harness 平台 API 的託管 OAuth／服務路由憑證無法用於直接向 Split.io 發出請求的驗證。fme_feature_flag 支援完整的生命週期管理：建立（需要 traffic_type_id）、列出、取得、更新中繼資料、刪除，以及 kill／restore／archive／unarchive 等執行操作。使用 fme_traffic_type 探索流量類型 ID，使用 fme_identity 建立／更新身分屬性，並使用 fme_standard_segment／fme_segment_keys 檢視標準區段及新增成員金鑰。fme_rule_based_segment 提供目標區段的 CRUD 操作，而 fme_rule_based_segment_definition 則管理特定環境的區段規則，並支援啟用／停用及變更請求審核流程。

GitOps

資源類型	列出	取得	執行操作
`gitops_agent`	x	x
`gitops_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

混沌工程（Chaos Engineering）

資源類型	列出	取得	建立	更新	刪除	執行操作
`chaos_experiment`	x	x	x		x	`run`, `stop`
`chaos_experiment_run`		x
`chaos_experiment_variable`	x
`chaos_component_variable`		x
`chaos_input_set`	x	x	x	x	x
`chaos_experiment_template`	x	x			x	`create_from_template`
`chaos_probe`	x	x	x		x	`enable`, `verify`
`chaos_probe_in_run`	x
`chaos_probe_template`	x	x			x
`chaos_infrastructure`	x
`chaos_k8s_infrastructure`	x	x				`check_health`
`chaos_environment`	x
`chaos_hub`	x	x	x	x	x
`chaos_hub_fault`	x
`chaos_fault`	x	x			x
`chaos_fault_template`	x	x			x
`chaos_fault_experiment_run`	x
`chaos_action`	x	x			x
`chaos_action_template`	x	x			x
`chaos_loadtest`	x	x	x		x	`run`, `stop`
`chaos_application_map`	x	x
`discovered_namespace`	x
`discovered_service`	x
`discovered_network_map`	x
`chaos_guard_condition`	x	x			x
`chaos_guard_rule`	x	x			x	`enable`
`chaos_recommendation`	x	x
`chaos_risk`	x	x
`chaos_dr_test`	x		x
`scanned_risk`	x	x				`occurrences`, `summary_by_service`
`chaos_risk_rule`	x	x
`chaos_risk_scan`	x	x	x	x	x	`retry`, `abort`, `report`, `report_download`, `heatmap`

雲端成本管理（CCM）

資源類型	列出	取得	建立	更新	刪除	執行操作
`cost_perspective`	x	x	x	x	x
`cost_breakdown`	x
`cost_timeseries`	x
`cost_summary`	x	x
`cost_recommendation`	x	x				`update_state`, `override_savings`, `create_jira_ticket`, `create_snow_ticket`
`cost_anomaly`	x
`cost_anomaly_summary`		x
`cost_category`	x	x
`cost_account_overview`		x
`cost_filter_value`	x
`cost_recommendation_stats`		x
`cost_recommendation_detail`		x
`cost_commitment`		x

軟體工程洞察（SEI）

SEI 資源為提升 token 效率而整合。使用 metric 或 aspect 參數取得 DORA、團隊／組織樹狀結構詳細資料，以及 AI 洞察。

資源類型	列出	取得	執行操作
`sei_metric`	x
`sei_productivity_metric`		x
`sei_dora_metric`		x	傳入 `metric`：deployment_frequency、change_failure_rate、mttr、lead_time 或 *_drilldown
`sei_team`	x	x
`sei_team_detail`	x		傳入 `aspect`：integrations、developers、integration_filters
`sei_org_tree`	x	x
`sei_org_tree_detail`	x	x	傳入 `aspect`：efficiency_profile、productivity_profile、business_alignment_profile、integrations、teams
`sei_business_alignment`	x	x	傳入 `aspect`：feature_metrics、feature_summary，取得時使用 drilldown
`sei_ai_usage`	x	x	傳入 `aspect`：metrics、breakdown、summary、top_languages
`sei_ai_adoption`	x	x	傳入 `aspect`：metrics、breakdown、summary
`sei_ai_impact`		x	傳入 `aspect`：pr_velocity、rework
`sei_ai_raw_metric`	x

軟體供應鏈保證 (SCS)

資源類型	列出	取得
`scs_artifact_source`	x
`artifact_security`	x	x
`scs_artifact_component`	x
`scs_artifact_remediation`		x
`scs_chain_of_custody`		x
`scs_compliance_result`	x
`code_repo_security`	x	x
`scs_sbom`		x

證據庫

Evidence Vault 儲存 in-toto 證明（SDLC 證據）。List 透過 resource_scope 支援帳戶/組織/專案範圍。單一自由文字篩選（pipeline、單獨 artifact、gitoid）使用 search_term；額外的 Name 約束使用 filters.subject_name；subject 內容摘要使用 filters.subject_digest。Get 透過 gitoid_sha256 查詢，並需要 org_id/project_id（來自列表列）。Download（harness_execute 動作 download）回傳有時效限制的 download_url — 務必向使用者顯示該連結。需要功能旗標 SCS_EVIDENCE_VAULT。

資源類型	列出	取得	建立	更新	刪除	執行動作
`attestation`	x	x				`download`

安全性測試編排 (STO)

資源類型	列出	建立	執行動作
`security_issue`	x
`security_issue_filter`	x
`security_exemption`	x	x	`approve`, `reject`
`remediation_diff`	x

security_exemption 建立是一個 high_write 操作。伺服器從已驗證的 PAT 推導出 requester_id，設定 exemptFutureOccurrences=true，並在未提供時將 duration_days 預設為 30。若要列出豁免，請傳入較小的明確頁面大小（例如 filters: { "status": "Pending", "size": 5 }），並遵循每個回應中回傳的 _nextPageHint。

安全性豁免執行工作流程：

使用 harness_list 搭配 resource_type="security_exemption" 和明確的 status，例如 Pending、Approved、Rejected、Expired 或 Canceled。
使用 harness_execute 搭配 action="approve" 和必要的 body.scope：CURRENT、ACCOUNT、ORG 或 PROJECT。CURRENT 在豁免的現有範圍內核准；其他範圍在內部使用 STO promote 端點。伺服器在省略時會從已驗證的使用者自動填入 body.approver_id；body.comment 為選填。
使用 action="reject" 拒絕豁免。省略時 body.approver_id 也會自動填入。
沒有單獨的 promote 執行動作。當請求的結果是在帳戶、組織或專案範圍內核准時，請使用 action="approve" 搭配非 CURRENT 的 body.scope。

存取控制

資源類型	列出	取得	建立	刪除
`user`	x	x
`user_group`	x	x	x	x
`service_account`	x	x	x	x
`role`	x	x	x	x
`role_assignment`	x		x
`resource_group`	x	x	x	x
`permission`	x

治理

資源類型	列出	取得	建立	更新	刪除
`policy`	x	x	x	x	x
`policy_set`	x	x	x	x	x
`policy_evaluation`	x	x

部署凍結

資源類型	列出	取得	建立	更新	刪除	執行動作
`freeze_window`	x	x	x	x	x	`toggle_status`
`global_freeze`		x				`manage`

服務覆寫

資源類型	列出	取得	建立	更新	刪除	執行動作
`service_override`	x	x	x	x	x

設定

資源類型	列出	取得	建立	更新	刪除	執行動作
`setting`	x

MCP 提示

DevOps

提示	描述	參數
`build-deploy-app`	端對端 CI/CD 工作流程：掃描 git 儲存庫、產生 CI 管道（建置並推送 Docker 映像）、探索或產生 K8s 清單、建立 CD 管道並部署——在 CI 失敗時自動重試（最多 5 次），在 CD 失敗時則需使用者許可（最多 3 次）。重試耗盡時，提供 Harness UI 深層連結至所有已建立的資源，供手動調查。	`repoUrl` (必填)、`imageName` (必填)、`projectId` (選填)、`namespace` (選填)
`debug-pipeline-failure`	分析失敗的執行：接受執行 ID、管道 ID 或 Harness URL。透過 `harness_diagnose` 取得階段/步驟明細、失敗詳情、委派代理資訊及失敗步驟日誌，然後提供根本原因分析與建議修正。自動追蹤鏈式管道失敗。	`executionId` (選填)、`projectId` (選填)
`pipeline_summarizer`	擷取並總結管道執行的所有步驟日誌。使用 `harness_diagnose` 搭配 `include_logs: true, include_all_step_logs: true` 取得每個步驟的日誌，然後呈現一個表格，包含步驟名稱、狀態、持續時間與概況（以日誌為基礎的摘要）。不會跳過任何步驟。	`executionId` (選填)、`projectId` (選填)
`create-pipeline`	根據自然語言需求產生新的管道 YAML，並檢視現有資源以取得上下文。	`description` (必填)、`projectId` (選填)
`create-agent`	互動式建置 Harness AI 代理程式——檢查現有代理程式、收集需求、使用代理程式管道 schema 產生代理程式 YAML 規格，與使用者確認後，透過 `harness_create`/`harness_update` 建立或更新。	`agent_name` (必填)、`task_description` (必填)、`org_id` (選填)、`project_id` (選填)
`onboard-service`	逐步引導將新服務上線，包含環境與部署管道。	`serviceName` (必填)、`projectId` (選填)
`dora-metrics-review`	檢視 DORA 指標（部署頻率、變更失敗率、MTTR、前置時間），並提供 Elite/High/Medium/Low 分類與改善建議。	`teamRefId` (選填)、`dateStart` (選填)、`dateEnd` (選填)
`setup-gitops-application`	引導完成 GitOps 應用程式上線——驗證代理程式、叢集、儲存庫，並建立應用程式。	`agentId` (必填)、`projectId` (選填)
`chaos-resilience-test`	設計混沌實驗以測試服務韌性，包含故障注入、探針與預期結果。	`serviceName` (必填)、`projectId` (選填)
`feature-flag-rollout`	規劃並執行漸進式功能旗標在各環境的推出，並設置安全關卡。	`flagIdentifier` (必填)、`projectId` (選填)
`migrate-pipeline-to-template`	分析現有管道，並從中萃取可重用的階段/步驟模板。	`pipelineId` (必填)、`projectId` (選填)
`delegate-health-check`	檢查委派代理的連線、健康狀態、權杖狀態，並疑難排解基礎設施問題。	`projectId` (選填)
`developer-portal-scorecard`	檢閱服務的 IDP 評分卡，找出改善開發者體驗的落差。	`projectId` (選填)
`pending-approvals`	尋找等待核准的管道執行，顯示詳情，並提供核准或拒絕的選項。	`projectId` (選填)、`orgId` (選填)、`pipelineId` (選填)

FinOps

提示	描述	參數
`optimize-costs`	分析雲端成本資料，顯示建議與異常，並按潛在節省金額優先排序。	`projectId` (選填)
`cloud-cost-breakdown`	深入分析服務、環境或叢集的雲端成本，包含趨勢分析與異常偵測。	`perspectiveId` (選填)、`projectId` (選填)
`commitment-utilization-review`	分析預留執行個體及節省方案使用率，找出浪費並最佳化承諾。	`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

Prompt	描述	參數
`code-review`	審查拉取請求 — 分析差異、提交、檢查與評論，針對錯誤、安全性、效能與程式碼風格提供結構化回饋	`repoId` (必填)、`prNumber` (必填)、`projectId` (選填)
`pr-summary`	根據分支的提交歷史與差異自動產生 PR 標題與描述	`repoId` (必填)、`sourceBranch` (必填)、`targetBranch` (選填，預設：main)、`projectId` (選填)
`branch-cleanup`	分析儲存庫中的分支，並建議刪除過時或已合併的分支	`repoId` (必填)、`projectId` (選填)

MCP 資源

資源 URI	描述	MIME 類型
`pipeline:///{pipelineId}`	Pipeline YAML 定義	`application/x-yaml`
`pipeline:///{orgId}/{projectId}/{pipelineId}`	Pipeline YAML（含明確範圍）	`application/x-yaml`
`executions:///recent`	最近 10 次 pipeline 執行摘要	`application/json`
`schema:///pipeline`	Harness pipeline JSON Schema	`application/schema+json`
`schema:///template`	Harness template JSON Schema	`application/schema+json`
`schema:///trigger`	Harness trigger JSON Schema	`application/schema+json`
`schema:///pipeline_v1` (Alpha)	Harness V1 pipeline JSON Schema（簡化的 stages/steps 格式）	`application/schema+json`
`schema:///agent-pipeline`	Harness AI agent pipeline JSON Schema	`application/schema+json`

工具集篩選

預設情況下，39 個工具集中有 38 個已啟用。有一個工具集為選擇加入，且不包含在預設值中：

ansible — Harness Ansible（inventories、playbooks、hosts、activity）。由於其為專案範圍且增加了許多使用者不需要的概念，因此採選擇加入方式。

使用 `+` 前綴新增工具集

使用 + 前綴，將選擇加入的工具集與所有預設值一起明確包含：

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

移除預設工具集

使用 - 前綴排除您不需要的工具集：

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

結合 + 與 -

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

明確允許清單

明確的逗號分隔清單（無前綴）會完全取代預設值。僅啟用列出的工具集：

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

可用的工具集名稱：

工具集	資源類型
`platform`	organization, project
`pipelines`	pipeline, pipeline_v1, pipeline_dynamic_execution, execution, execution_inputs, trigger, pipeline_summary, input_set, approval_instance
`agents`	agent, agent_run
`services`	service
`environments`	environment
`connectors`	connector, connector_catalogue
`infrastructure`	infrastructure
`secrets`	secret
`logs`	execution_log
`audit`	audit_event
`delegates`	delegate, delegate_token
`repositories`	repository, branch, commit, file_content, tag, repo_rule, space_rule
`registries`	registry, artifact, artifact_version, artifact_file
`file_store`	file_store
`templates`	template
`dashboards`	dashboard, dashboard_data
`idp`	idp_entity, scorecard, scorecard_check, scorecard_stats, scorecard_check_stats, idp_score, idp_workflow, idp_tech_doc
`pull-requests`	pull_request, pr_reviewer, pr_comment, pr_check, pr_activity
`feature-flags`	fme_workspace, fme_environment, fme_feature_flag, fme_feature_flag_definition, fme_rollout_status, fme_rule_based_segment, fme_rule_based_segment_definition, fme_traffic_type, fme_identity, fme_standard_segment, fme_segment_keys
`gitops`	gitops_agent, 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
`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_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_application_map, 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
`access_control`	user, user_group, service_account, role, role_assignment, resource_group, permission
`governance`	policy, policy_set, policy_evaluation
`freeze`	freeze_window, global_freeze
`overrides`	service_override
`settings`	setting
`knowledge-graph`	kg_queryable_type_summary, kg_grammar, hql_query
`semantic-layer`	kg_type, kg_related_type
`ai-evals`	eval_dataset, eval_dataset_item, evaluation, eval_run, eval_run_item, eval_run_by_eval, eval_metric, eval_metric_set, eval_metric_set_entry, eval_suite, eval_suite_evaluation, eval_suite_run, eval_target, eval_annotation, eval_analytics, eval_git_settings, eval_registry_item, eval_git_registration, online_eval
`iacm`	iacm_workspace, iacm_variable_set, iacm_resource, iacm_module, iacm_workspace_costs, iacm_activity_resource_change
`ansible` (選擇加入)	ansible_inventory, ansible_playbook, ansible_host, ansible_host_activity, ansible_activity

架構

                 +------------------+
                 |   AI Agent       |
                 |  (Claude, etc.)  |
                 +--------+---------+
                          |  MCP (stdio or HTTP)
                 +--------v---------+
                |    MCP Server     |
                | 11 Generic Tools  |
                 +--------+---------+
                          |
                 +--------v---------+
                |    Registry       |  <-- Declarative resource definitions
                |  38 Toolsets      |      (data files, not code)
                |  224 Resource Types|
                 +--------+---------+
                          |
                 +--------v---------+
                 |  HarnessClient    |  <-- Auth, retry, rate limiting
                 +--------+---------+
                          |  HTTPS
                 +--------v---------+
                 |  Harness REST API |
                 +-------------------+

運作方式

工具是通用動詞：harness_list、harness_get 等。它們接受 resource_type 參數，以路由到正確的 API 端點。
註冊表將每個 resource_type 映射到 ResourceDefinition——一種宣告式資料結構，指定 HTTP 方法、URL 路徑、路徑/查詢參數映射，以及回應萃取邏輯。
分派解析資源定義、建構 HTTP 請求（路徑替換、查詢參數、resource_scope 感知的帳戶/組織/專案注入）、透過 HarnessClient 呼叫 Harness API，並萃取相關的回應資料。
工具集篩選（HARNESS_TOOLSETS）控制在啟動時哪些資源定義會載入註冊表。
結構化輸出以 MCP outputSchema 宣告；harness_list 會將陣列和常見的清單包裝器強制轉換為物件形狀的 structuredContent，以支援嚴格的用戶端。
深層連結會自動附加到回應中，為每個資源提供直接的 Harness UI URL。
精簡模式會從清單結果中移除冗長的中繼資料，僅保留可操作的欄位（身分、狀態、類型、時間戳記、深層連結），以最小化 token 用量。

新增資源類型

在 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 徵求確認在操作風險需要時提示使用者確認——僅限 medium_write、high_write 和 destructive 操作。低風險的建立／更新／讀取（例如 pipeline.create、pipeline.update、hql_query.run）會靜默執行，不顯示提示。當出現提示時，使用者會看到即將執行的內容並選擇接受或拒絕，為實際變更或執行的操作提供真正的人員介入核准。

運作方式：

LLM 呼叫風險為 medium_write+ 的寫入工具（例如 harness_delete、harness_execute pipeline.run）。低風險的建立／更新／讀取不會顯示提示。
伺服器向用戶端傳送徵求確認請求，包含操作摘要和一個 confirm 核取方塊（預設勾選）。
使用者檢視詳細資訊，點擊接受（勾選 confirm）或拒絕／取消。
若勾選 confirm: true 接受，則繼續執行操作。若接受但未勾選 confirm、拒絕或取消，操作會被封鎖並告知 LLM（明確拒絕具有權威性，不會被工具呼叫上的 confirm: true 繞過）。

用戶端支援：

用戶端	徵求確認支援
Cursor	是
VS Code (Copilot)	是
Claude Desktop	尚未支援
Devin Desktop	尚未支援
MCP Inspector	是

當用戶端缺少支援時，徵求確認行為因操作風險而異：

風險等級	用戶端支援徵求確認	是否傳遞 `confirm: true`	行為
`read`、`low_write`	任何	任何	靜默執行——不顯示提示（`confirm` 在此風險層級無效）
`medium_write`、`high_write`、`destructive`	是	任何	提示使用者。僅當使用者勾選 `confirm: true`（schema 的預設值）接受時才繼續。明確拒絕、取消，或接受但未勾選 `confirm: false`（使用者取消勾選）具有權威性，不會被工具呼叫上的 `confirm: true` 繞過。接受但缺少 `confirm` 欄位，視為用戶端未能顯示可用提示——可透過使用 `confirm: true` 重試來回復
`medium_write`、`high_write`、`destructive`	否	否	封鎖（回傳錯誤，並提示使用 `confirm: true` 重試）
`medium_write`、`high_write`、`destructive`	否	是	繼續執行（非互動式自動化的明確選擇加入）
任何（等於或低於 `HARNESS_AUTO_APPROVE_RISK`）	任何	任何	自動核准，不顯示提示

若 elicitInput 在執行時間失敗（傳輸錯誤、不支援的方法），且操作風險為 medium_write+，則呼叫會被封鎖，除非呼叫者傳遞 confirm: true。當用戶端無法顯示提示或回傳無效的接受（{action: "accept"} 缺少確認欄位）時，confirm: true 會作為後備機制被採用，但它不會覆蓋已完成徵求確認交握之用戶端的明確拒絕／取消。

自主模式

自主模式表示伺服器會繼續執行所有操作——包括寫入和破壞性動作——而不提示確認。透過以下設定啟用：

HARNESS_AUTO_APPROVE_RISK=all

這是部署層級的上限：一旦設定，個別工作階段無法超越它（但可透過 x-harness-auto-approve-risk 標頭為每個工作階段選擇更嚴格的門檻）。

或在您的 MCP 用戶端設定中：

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

**部分自主：**您也可以僅自動核准特定風險等級以下的操作，同時仍對較高風險的操作顯示提示：

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

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

值	自動核准的內容
`none`（預設）	無——沒有自動核准門檻
`low_write`	讀取 + 低風險寫入
`medium_write`	讀取 + 低 + 中風險寫入
`high_write`	讀取 + 低 + 中 + 高風險寫入
`all`	所有操作，包括破壞性操作

自主模式警告： HARNESS_AUTO_APPROVE_RISK=all 會跳過所有操作的確認，包括 harness_delete。請謹慎使用，並考慮搭配 HARNESS_TOOLSETS 以限制可用的資源類型。

遷移注意事項： HARNESS_SKIP_ELICITATION=true 仍受支援，並映射到 HARNESS_AUTO_APPROVE_RISK=all。會記錄棄用警告到 stderr。若兩者皆設定，HARNESS_AUTO_APPROVE_RISK 優先。

安全性

祕密永遠不會暴露。 secret 資源類型僅回傳中繼資料（名稱、類型、範圍）——祕密值永遠不會包含在任何回應中。
需要確認的操作在可用時使用徵求確認。 當寫入或執行操作具有 medium_write、high_write 或 destructive 風險時，harness_create、harness_update、harness_delete 和 harness_execute 會在繼續前嘗試 MCP 徵求確認（請參閱徵求確認）。低風險操作（read、low_write——例如 pipeline.create、pipeline.update、hql_query.run）會靜默執行，不顯示提示。
中風險及以上預設失敗關閉。 若無法為 medium_write、high_write 或 destructive 操作取得確認，則會封鎖執行，而非盲目執行。可使用 HARNESS_AUTO_APPROVE_RISK 覆寫以支援自主工作流程。
CORS 僅限同源。 HTTP 傳輸僅允許同源請求，防止惡意網站針對 localhost 上的 MCP 伺服器發動 CSRF 攻擊。
HTTP 速率限制。 HTTP 傳輸強制每個 IP 每分鐘 60 次請求，以防止請求洪水。
API 速率限制。 Harness API 用戶端強制每秒 10 次請求的限制，以避免觸發上游速率限制。
分頁界限強制執行。 清單查詢上限為總計 10,000 個項目，每頁 100 個，以防止記憶體耗盡。
指數退避重試。 暫時性失敗（HTTP 429、5xx）會以指數退避和抖動進行重試。
僅綁定 localhost。 HTTP 傳輸預設綁定到 127.0.0.1——無法從網路存取。
無 stdout 日誌。 所有日誌都寫入 stderr，以避免破壞 stdio JSON-RPC 傳輸。

互補技能

Harness MCP 伺服器與 Harness Skills 搭配良好——這是一組現成的 Claude Code 技能（斜線指令），專為常見的 Harness 工作流程設計。將它們與此 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: ...`	一個或多個工具集名稱無法辨識	僅使用 Toolset Filtering 中的名稱（需完全相符）
HTTP `mcp-session-id header is required...`	未包含 session header 就發送了 session 請求	先發送 `initialize`，然後在 `POST/GET/DELETE /mcp` 中包含 `mcp-session-id`
HTTP `Session not found...`	Session 在閒置 `MCP_SESSION_TTL_MS` 毫秒後過期，或已關閉	重新執行 `initialize` 以建立新 session，然後使用新的 header 重試
在 `/mcp` 上出現 HTTP `405 Method Not Allowed`	MCP 端點不支援的方法	僅使用 `POST`、`GET`、`DELETE` 或 `OPTIONS`
HTTP `Invalid request`	JSON body 無效或請求 body 超過 `HARNESS_MAX_BODY_SIZE_MB`	驗證 JSON payload 的大小/格式；如有需要請增加 `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`
Pipeline 執行在預檢階段因未解析的必要輸入而失敗	提供的 `inputs` 未涵蓋必要的執行時期佔位符	取得 `runtime_input_template`、提供缺少的簡單鍵，或對結構化輸入使用 `input_set_ids`
Pipeline CI 簡寫（`branch`、`tag`、`pr_number`、`commit_sha`）未生效	已提供 `inputs.build`，因此刻意跳過了簡寫展開	移除 `inputs.build` 以使用簡寫展開，或保留完整的明確 `build` 結構
Pipeline 執行載入了錯誤的 YAML 修訂版本	Pipeline 定義儲存在 Git 中，且執行未指定所需的 pipeline 分支	在 `run` 動作上傳入 `params.pipeline_branch`；這會對應到 Harness `pipelineBranchName`
`wait: true` 回傳 `_wait.error`	Pipeline 觸發成功，但伺服器端輪詢失敗	在決定是否重新執行之前，使用 `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 主機，並使用 `harness_get(resource_type="execution_log", ...)` 或 `harness_diagnose(..., include_logs=true)`，而不是繞過 MCP 用戶端
`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 payload	在 `body` 中提供完整的 `template_yaml` 字串；若要刪除，請傳入 `version_label` 以刪除單一版本（省略則刪除所有版本）
啟動時出現 `HARNESS_BASE_URL must use HTTPS`	`HARNESS_BASE_URL` 被設定為 HTTP URL	使用 HTTPS，或為本機開發設定 `HARNESS_ALLOW_HTTP=true`

授權

MIT

Harness

你可以用 Harness MCP 做什麼？

文件

Harness MCP Server 2.0

為什麼使用這個 MCP 伺服器

先決條件

快速入門

選項 0：託管的 Harness MCP

選項 1：npx（建議）

選項 2：全域安裝

選項 3：從原始碼建置

Anthropic MCP Directory 套件

CLI 使用方式

HTTP 傳輸

多使用者模式

用戶端設定

託管的 Harness MCP

Claude Desktop（claude_desktop_config.json）

Claude Code（透過 claude mcp add）

Cursor（.cursor/mcp.json）

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

MCP Gateway

Docker MCP Gateway

Portkey

LiteLLM

Envoy AI Gateway

Kong

其他 Gateway

Docker

Kubernetes

設定

語意搜尋

HTTPS 強制執行

稽核日誌

工具參考

Schema 查詢工作流程

工具範例

管線執行工作流程（建議）

動態管線執行

執行輸入鑑識（Execution Input Forensics）

管線執行等待模式（Pipeline Execute Wait Mode）

管線儲存模式

資源類型

平台（Platform）

管線（Pipelines）

AI 代理程式（AI Agents）

服務（Services）

環境（Environments）

連接器（Connectors）

基礎設施（Infrastructure）

機密（Secrets）

執行日誌（Execution Logs）

稽核軌跡（Audit Trail）

代理程式（Delegates）

程式碼儲存庫（Code Repositories）

Artifact Registries

File Store

Templates

Dashboards

Database DevOps

Infrastructure as Code Management (IaCM)

Internal Developer Portal (IDP)

Pull Requests

Feature Flags

GitOps

混沌工程（Chaos Engineering）

雲端成本管理（CCM）

軟體工程洞察（SEI）

軟體供應鏈保證 (SCS)

證據庫

安全性測試編排 (STO)

存取控制

治理

部署凍結

服務覆寫

設定

MCP 提示

DevOps

FinOps

DevSecOps

Claude Desktop（`claude_desktop_config.json`）

Claude Code（透過 `claude mcp add`）

Cursor（`.cursor/mcp.json`）

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

使用 `+` 前綴新增工具集