Harness

Máy chủ Harness MCP 2.0

Máy chủ MCP (Model Context Protocol) cung cấp cho các tác nhân AI quyền truy cập đầy đủ vào nền tảng Harness.io thông qua 11 công cụ hợp nhất và 255 loại tài nguyên.

Tại Sao Nên Dùng Máy Chủ MCP Này

Hầu hết các máy chủ MCP ánh xạ một công cụ cho mỗi điểm cuối API. Với một nền tảng rộng lớn như Harness, điều đó có nghĩa là hơn 240 công cụ — và các LLM hoạt động kém hơn trong việc chọn công cụ khi số lượng tăng lên. Cửa sổ ngữ cảnh bị lấp đầy bởi các lược đồ, và mỗi điểm cuối mới đồng nghĩa với mã mới.

Máy chủ này được xây dựng khác biệt:

• 11 công cụ, 255 loại tài nguyên. Hệ thống điều phối dựa trên registry định tuyến harness_list, harness_get, harness_create, v.v. đến bất kỳ tài nguyên Harness nào — pipeline, dịch vụ, môi trường, tổ chức, dự án, cờ tính năng, dữ liệu chi phí, v.v. LLM chọn từ 11 công cụ thay vì hàng trăm.
• Bao phủ toàn bộ nền tảng. 41 bộ công cụ mặc định bao gồm CI/CD, GitOps, Cờ Tính năng, Quản lý Chi phí Đám mây, Kiểm thử Bảo mật, Kỹ thuật Hỗn loạn, DevOps Cơ sở dữ liệu, Cổng thông tin Nhà phát triển Nội bộ, Chuỗi cung ứng Phần mềm, Quản lý Cơ sở hạ tầng dưới dạng Mã, Quản lý Phát hành, Quản trị, Ghi đè Dịch vụ, Đồ thị Tri thức, v.v. Có thể chọn thêm phạm vi Ansible và đánh giá khả năng quan sát khi cần.
• Quy trình làm việc đa dự án ngay lập tức. Các tác nhân khám phá tổ chức và dự án một cách động — không cần biến môi trường được mã hóa cứng. Hỏi "hiển thị các lần thực thi thất bại trên tất cả các dự án" và tác nhân có thể điều hướng toàn bộ hệ thống phân cấp tài khoản.
• 35 mẫu lời nhắc. Các lời nhắc được xây dựng sẵn cho các quy trình làm việc phổ biến: xây dựng và triển khai ứng dụng từ đầu đến cuối, gỡ lỗi pipeline thất bại, xem xét chỉ số DORA, phân loại lỗ hổng, tối ưu hóa chi phí đám mây, kiểm toán kiểm soát truy cập, lập kế hoạch triển khai cờ tính năng, xem xét yêu cầu kéo, phê duyệt pipeline đang chờ xử lý, v.v.
• Hoạt động ở mọi nơi. Truyền tải Stdio cho các máy khách cục bộ (Claude Desktop, Cursor, Devin Desktop), truyền tải HTTP cho các triển khai từ xa/dùng chung, sẵn sàng cho Docker và Kubernetes.
• Khởi động không cần cấu hình. Chỉ cần cung cấp khóa API Harness. ID tài khoản được tự động trích xuất từ mã thông báo PAT và SAT, mặc định org/project là tùy chọn, và bộ lọc bộ công cụ cho phép bạn chỉ hiển thị những gì bạn cần.
• Có thể mở rộng theo thiết kế. Thêm một tài nguyên Harness mới có nghĩa là thêm một tệp dữ liệu khai báo — không cần đăng ký công cụ mới, không thay đổi lược đồ, không cập nhật lời nhắc.

Điều Kiện Tiên Quyết

Trước khi cài đặt hoặc chạy máy chủ, bạn cần có khóa API Harness:

1. Đăng nhập vào tài khoản Harness của bạn
2. Đi tới Hồ sơ của tôi → Khóa API → + Khóa API mới
3. Tạo Mã thông báo mới dưới khóa API — thao tác này tạo PAT hoặc SAT ở định dạng <prefix>.<accountId>.<tokenId>.<secret>
4. Lưu mã thông báo ở nơi an toàn — bạn sẽ cần nó trong bước tiếp theo

Để biết hướng dẫn chi tiết, hãy xem Bắt đầu nhanh với API Harness.

Bắt Đầu Nhanh

Tùy chọn 0: Harness MCP được lưu trữ

Nếu tài khoản Harness của bạn đã bật dịch vụ MCP được lưu trữ, các máy khách hỗ trợ máy chủ MCP từ xa có thể kết nối trực tiếp đến điểm cuối được quản lý thay vì chạy máy chủ cục bộ.

Quan trọng: Dịch vụ MCP được lưu trữ sử dụng OAuth nền tảng Harness, không phải HARNESS_API_KEY. Dịch vụ này cũng phải được Hỗ trợ Harness bật/cấu hình cho từng tài khoản trước khi điểm cuối có thể được sử dụng.

Xem Harness MCP được lưu trữ để biết các ví dụ cấu hình.

Tùy chọn 1: npx (Khuyến nghị)

Không cần cài đặt — chỉ cần chạy:

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

Hoặc cấu hình khóa API trong máy khách AI của bạn (xem Cấu hình Máy khách bên dưới).

# 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

Lưu ý: ID tài khoản được tự động trích xuất từ mã thông báo PAT và SAT (pat.<accountId>... hoặc sat.<accountId>...), vì vậy HARNESS_ACCOUNT_ID chỉ cần thiết cho các khóa API không có phân đoạn tài khoản được nhúng.

Tùy chọn 2: Cài đặt Toàn cầu

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

Tùy chọn 3: Xây dựng từ Mã nguồn

Dành cho phát triển hoặc tùy chỉnh:

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

Gói Thư mục MCP Anthropic

Tệp kê khai gói MCPB nằm trong [mcp-directory/](mcp-directory/), và biểu tượng gói 512×512 được theo dõi tại [icon.png](icon.png) trong thư mục gốc của kho lưu trữ. Kho lưu trữ được đóng gói chứa manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json ở cấp gốc và node_modules/ ở chế độ sản xuất.

Để giữ kho lưu trữ nhỏ, hãy xây dựng các gói MCPB từ một thư mục tạm:

pnpm prepare:mcpb

Thư mục tạm được ghi vào dist/mcpb/ với các phụ thuộc sản xuất được cài đặt từ npm-shrinkwrap.json bằng bố cục phẳng của npm. CLI MCPB chính thức được ghim xác thực nó và tạo dist/harness-mcp-server-<version>.mcpb.

Các thẻ phiên bản khớp với v*.*.* tự động xuất bản gói đó vào Bản phát hành GitHub tương ứng. Để bổ sung cho một bản phát hành hiện có mà không xuất bản lại npm, hãy chạy quy trình làm việc Release theo cách thủ công với đầu vào release_tag của nó (ví dụ: v3.2.20). Quy trình làm việc kiểm tra và xây dựng chính xác thẻ đó trước khi thay thế chỉ tài sản MCPB có phiên bản của nó.

Sử dụng 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

Truyền tải mặc định là stdio nếu không được chỉ định. Sử dụng http cho các triển khai từ xa/dùng chung.

Truyền tải HTTP

Khi chạy ở chế độ HTTP, máy chủ hiển thị:

Điểm cuối	Phương thức	Mô tả
/mcp	POST	Điểm cuối MCP JSON-RPC (yêu cầu khởi tạo + phiên)
/mcp	GET	Luồng SSE cho các thông báo do máy chủ khởi tạo (tiến trình, trích xuất)
/mcp	DELETE	Chấm dứt một phiên MCP đang hoạt động
/mcp	OPTIONS	Kiểm tra trước CORS
/health	GET	Kiểm tra sức khỏe — trả về { "status": "ok", "sessions": <count> }
/.well-known/oauth-protected-resource	GET	Siêu dữ liệu RFC 9728 khi HARNESS_MCP_MODE=oauth
/.well-known/oauth-protected-resource/mcp	GET	Siêu dữ liệu RFC 9728 nhận biết đường dẫn cho tài nguyên /mcp mặc định

Truyền tải HTTP chạy ở chế độ dựa trên phiên. Một phiên MCP mới được tạo trên initialize, máy chủ trả về tiêu đề mcp-session-id, và các yêu cầu tiếp theo cho phiên đó phải bao gồm cùng một tiêu đề.

Các ràng buộc vận hành ở chế độ HTTP:

• Đặt HARNESS_MCP_AUTH_TOKEN cho các triển khai đơn người dùng và đa người dùng dùng chung hoặc truy cập từ xa. Khi được đặt, mọi yêu cầu POST, GET và DELETE đến /mcp phải bao gồm Authorization: Bearer <token>.
• Chế độ OAuth chấp nhận mã thông báo truy cập HarnessID thay vì HARNESS_MCP_AUTH_TOKEN và có thể liên kết với địa chỉ không phải loopback mà không cần chọn không xác thực.
• Các liên kết đơn người dùng và đa người dùng không phải loopback yêu cầu HARNESS_MCP_AUTH_TOKEN theo mặc định. Để chạy không xác thực trên giao diện không phải loopback, hãy đặt HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true một cách rõ ràng.
• POST /mcp không có mcp-session-id phải là yêu cầu initialize.
• POST /mcp, GET /mcp và DELETE /mcp cho các phiên hiện có yêu cầu tiêu đề mcp-session-id.
• GET /mcp được sử dụng cho các thông báo SSE (cập nhật tiến trình và lời nhắc trích xuất).
• Các phiên không hoạt động bị thu hồi sau MCP_SESSION_TTL_MS mili giây khi không có yêu cầu hoặc luồng SSE đang hoạt động (mặc định 1800000, hoặc 30 phút).
• GET /health là điểm cuối không phải MCP duy nhất.
• Kích thước phần thân yêu cầu được giới hạn bởi HARNESS_MAX_BODY_SIZE_MB (mặc định 10 MB).
• Đặt x-harness-pipeline-version: 0 hoặc 1 trên yêu cầu initialize để chọn tài nguyên pipeline V0 hoặc V1 cho phiên HTTP đó.
• Đặt x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all trên yêu cầu initialize để chọn ngưỡng tự động phê duyệt nghiêm ngặt hơn cho từng phiên. Máy chủ giới hạn giá trị này ở mức HARNESS_AUTO_APPROVE_RISK của cấp triển khai, vì vậy một phiên có thể giảm nhưng không thể mở rộng trần phê duyệt đã cấu hình.

Chế độ OAuth HarnessID

Đặt HARNESS_MCP_MODE=oauth để cho phép các máy khách MCP từ xa khám phá HarnessID và hoàn tất OAuth 2.1 Authorization Code với PKCE. Chế độ OAuth chỉ khả dụng với truyền tải HTTP. Các mặc định định tuyến HarnessID sản xuất, tài nguyên MCP và API được tích hợp sẵn:

HARNESS_MCP_MODE=oauth

Điều này mặc định cho nhà phát hành https://id.harness.io/idp/realms/HarnessIDP, tài nguyên https://mcp.harness.io/mcp, máy khách OAuth mcp-client và cơ sở API Harness https://mcp.harness.io/cli. Chỉ ghi đè chúng cho QA, phát triển cục bộ hoặc môi trường Harness khác.

HARNESS_API_KEY không được đặt trong chế độ này. HARNESS_MCP_OAUTH_JWKS_URI mặc định là <issuer>/protocol/openid-connect/certs, và HARNESS_ACCOUNT_ID là không cần thiết vì tài khoản đến từ mã thông báo.

Máy chủ xuất bản siêu dữ liệu tài nguyên được bảo vệ RFC 9728 và trả về thử thách này khi máy khách chưa xác thực:

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

Nó xác thực chữ ký RS256 của mã thông báo truy cập HarnessID, iss, thời hạn và sub bằng điểm cuối JWKS đã cấu hình, đồng thời kiểm tra mã thông báo được cấp cho HARNESS_MCP_OAUTH_CLIENT_ID thông qua yêu cầu azp. HARNESS_MCP_OAUTH_RESOURCE là định danh tài nguyên được bảo vệ RFC 9728 được sử dụng để khám phá và thử thách. Các mã thông báo truy cập HarnessID hiện tại sử dụng aud: account thay vì URL MCP, vì vậy tài nguyên không được so sánh với aud.

ID tài khoản đến từ yêu cầu HARNESS_MCP_OAUTH_ACCOUNT_CLAIM của mã thông báo (account_id theo mặc định), được phạm vi organization của HarnessID điền vào. Mỗi phiên lưu trữ mã thông báo truy cập của người gọi và chuyển tiếp nó đến API Harness dưới dạng Authorization: Bearer, vì vậy RBAC Harness và hồ sơ kiểm toán phản ánh người dùng đã đăng nhập thay vì một PAT dùng chung. Phiên được liên kết với sub và tài khoản mà nó được tạo: một yêu cầu sau đó có thể mang mã thông báo được làm mới, nhưng mã thông báo cho người dùng hoặc tài khoản khác sẽ bị từ chối.

Các máy khách thường chỉ cần URL tài nguyên MCP:

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

Máy khách đọc siêu dữ liệu tài nguyên được bảo vệ, khám phá HARNESS_MCP_OAUTH_ISSUER, sau đó sử dụng siêu dữ liệu RFC 8414 của máy chủ ủy quyền đó. Nếu máy khách không hỗ trợ đăng ký máy khách động, hãy sử dụng ID máy khách mcp-client đã đăng ký trước.

Xem OAuth HarnessID cho máy chủ MCP tự lưu trữ để biết danh sách kiểm tra QA Keycloak và các lệnh xác thực.

Chế độ Đa Người dùng

Đặt HARNESS_MCP_MODE=multi-user cho các triển khai HTTP dùng chung nơi mỗi máy khách xác thực với tư cách là một người dùng Harness khác nhau. Trong chế độ này:

• HARNESS_API_KEY không được đặt trong cấu hình máy chủ — máy chủ không giữ thông tin xác thực Harness.
• Mỗi phiên phải cung cấp x-harness-api-key trên yêu cầu initialize. x-harness-account-id chỉ được yêu cầu khi khóa API không nhúng phân đoạn tài khoản.
• Các phiên cũng có thể cung cấp tiêu đề x-harness-org và x-harness-project để đặt phạm vi mặc định cho phiên đó.
• Khóa API Harness truyền qua mọi lệnh gọi API Harness cho phiên đó, vì vậy dấu vết kiểm toán trong Harness phản ánh người dùng thực.
• HARNESS_MCP_AUTH_TOKEN là độc lập và vẫn có thể được sử dụng như một cổng bổ sung ở lớp truyền tải.

# 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 kiểm soát xác thực tiêu đề Host để bảo vệ chống ràng buộc lại DNS, và CORS giới hạn nguồn gốc trình duyệt. Cả hai đều không phải là xác thực; sử dụng HARNESS_MCP_AUTH_TOKEN hoặc một cổng/ proxy ngược đã xác thực để kiểm soát truy cập.

Cấu hình Máy khách

Lưu ý: HARNESS_ORG và HARNESS_PROJECT là tùy chọn. Chúng đặt ID tổ chức và ID dự án được sử dụng khi không được chỉ định cho mỗi lệnh gọi công cụ. Các tác nhân có thể khám phá tổ chức và dự án một cách động bằng harness_list(resource_type="organization") và harness_list(resource_type="project"). Các tên không dùng nữa HARNESS_DEFAULT_ORG_ID và HARNESS_DEFAULT_PROJECT_ID vẫn được chấp nhận để tương thích ngược.

Harness MCP được lưu trữ

Harness cũng hỗ trợ điểm cuối MCP được lưu trữ cho các tài khoản đã bật dịch vụ được quản lý. Điều này hữu ích khi bạn muốn một điểm cuối MCP từ xa dùng chung thay vì chạy npx harness-mcp-v2 hoặc tự lưu trữ truyền tải HTTP.

Quan trọng: Xác thực MCP được lưu trữ sử dụng Harness Platform OAuth. Nó không sử dụng HARNESS_API_KEY trong cấu hình máy khách. Tính khả dụng của MCP được lưu trữ được cấu hình theo từng tài khoản Harness, vì vậy bạn sẽ cần làm việc với Harness Support để bật/cấu hình cài đặt trước khi sử dụng.

Điểm cuối được lưu trữ https://mcp.harness.io/mcp là một dịch vụ được quản lý. Cấu hình MCP phía máy khách trong Claude, Cursor hoặc Cowork không thể ghi đè môi trường Harness mà nó định tuyến đến. Đối với Harness0 hoặc môi trường Harness SaaS riêng tư khác, hãy yêu cầu Harness Support bật/cấu hình MCP được lưu trữ cho môi trường đó, hoặc chạy máy chủ cục bộ/tự lưu trữ và đặt HARNESS_BASE_URL đến máy chủ Harness mục tiêu.

Ví dụ MCP được lưu trữ:

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

Ví dụ với cả mục nhập được lưu trữ và cục bộ:

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

Khắc phục sự cố npx ENOENT hoặc node: No such file or directory

Đây là lỗi khởi chạy tiến trình phía máy khách, không phải lỗi xác thực Harness. Máy chủ MCP chưa khởi động, vì vậy việc thay đổi HARNESS_API_KEY sẽ không ảnh hưởng đến spawn npx ENOENT.

Các ứng dụng GUI (Cursor, Claude Desktop, Devin Desktop, VS Code) không phải lúc nào cũng kế thừa PATH của shell, vì vậy chúng có thể không tìm thấy npx hoặc node sau khi tải lại cấu hình. Khắc phục bằng cách sử dụng đường dẫn tuyệt đối và đặt rõ ràng PATH trong khối env:

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

Tìm đường dẫn của bạn bằng which npx và which node trong terminal, sau đó đảm bảo thư mục chứa node được bao gồm trong giá trị PATH ở trên. Các vị trí phổ biến:

• Homebrew (macOS): /opt/homebrew/bin/npx
• nvm: ~/.nvm/versions/node/v20.x.x/bin/npx (chạy nvm which current để tìm đường dẫn chính xác)
• System Node: /usr/local/bin/npx

Claude Desktop (claude_desktop_config.json)

npx (cài đặt không cần cấu hình)

{
  "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 (cài đặt cục bộ)

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 (qua claude mcp add)

npx (cài đặt không cần cấu hình)

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

node (cài đặt cục bộ)

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

Sau đó đặt HARNESS_API_KEY trong môi trường của bạn hoặc tệp .env.

Cursor (.cursor/mcp.json)

npx (cài đặt không cần cấu hình, được khuyến nghị cho cấu hình Cursor cục bộ)

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

Chạy which npx trong terminal và sử dụng đường dẫn đầy đủ đó cho command; bao gồm thư mục từ which node ở đầu PATH.

node (cài đặt cục bộ)

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

Chạy which harness-mcp-v2 sau npm install -g harness-mcp-v2 và sử dụng đường dẫn đầy đủ đó cho command; bao gồm thư mục từ which node ở đầu PATH.

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

npx (cài đặt không cần cấu hình)

{
  "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 (cài đặt cục bộ)

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

Sử dụng bản dựng cục bộ từ mã nguồn?

Thay thế lệnh bằng đường dẫn đến index.js đã dựng của bạn:

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

MCP Gateway

Máy chủ Harness MCP hoàn toàn tương thích với MCP Gateways — proxy ngược cung cấp xác thực tập trung, quản trị, định tuyến công cụ và quan sát trên nhiều máy chủ MCP. Vì máy chủ triển khai giao thức MCP tiêu chuẩn với cả hai giao thức vận chuyển stdio và HTTP, nó hoạt động phía sau bất kỳ gateway tương thích MCP nào mà không cần thay đổi mã.

Tại sao sử dụng gateway?

• Quản lý thông tin xác thực tập trung — không có khóa API trong cấu hình tác nhân
• Ghi nhật ký quản trị & kiểm toán cho tất cả các lệnh gọi công cụ trên các nhóm
• Một điểm cuối duy nhất cho các tác nhân thay vì N kết nối đến N máy chủ MCP
• Kiểm soát truy cập — hạn chế nhóm nào có thể sử dụng công cụ nào

Docker MCP Gateway

Đăng ký máy chủ trong cấu hình Docker MCP Gateway của bạn:

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

Portkey

Thêm máy chủ Harness MCP vào Portkey MCP Gateway của bạn để quản trị doanh nghiệp, theo dõi chi phí và định tuyến đa LLM:

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

LiteLLM

Thêm vào cấu hình proxy LiteLLM của bạn:

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

Envoy AI Gateway

Máy chủ hoạt động với hỗ trợ MCP của Envoy AI Gateway qua giao thức vận chuyển HTTP:

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

Sau đó cấu hình Envoy để định tuyến đến http://localhost:8080/mcp như một backend MCP ngược dòng.

Kong

Sử dụng plugin AI MCP Proxy của Kong để hiển thị máy chủ Harness MCP thông qua cơ sở hạ tầng gateway Kong hiện có của bạn.

Các Gateway khác

Bất kỳ gateway nào hỗ trợ đặc tả MCP (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers, v.v.) đều có thể proxy máy chủ này. Đối với gateway dựa trên stdio, sử dụng giao thức vận chuyển mặc định. Đối với gateway dựa trên HTTP, khởi động máy chủ với giao thức vận chuyển http và trỏ gateway đến điểm cuối /mcp.

Docker

Xây dựng và chạy máy chủ như một container 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

Container chạy ở chế độ HTTP trên cổng 3000 theo mặc định với kiểm tra sức khỏe tích hợp.

Kubernetes

Triển khai đến cụm Kubernetes bằng các tệp kê khai được cung cấp:

# 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

Việc triển khai chạy 2 bản sao với các probe sẵn sàng/hoạt động, giới hạn tài nguyên và ngữ cảnh bảo mật không phải root. Dịch vụ hiển thị cổng 80 bên trong (nhắm mục tiêu cổng container 3000).

Cấu hình

Máy chủ tự động tải các biến môi trường từ tệp .env trong thư mục gốc dự án nếu có. Sao chép .env.example đến .env và điền các giá trị của bạn. Các biến môi trường cũng có thể được đặt qua shell hoặc cấu hình máy khách MCP của bạn.

Biến số	Bắt buộc	Mặc định	Mô tả
HARNESS_MCP_MODE	Không	single-user	Chế độ triển khai: single-user (khóa API dùng chung), multi-user (HTTP với khóa API theo phiên), hoặc oauth (HTTP với xác thực mã truy cập HarnessID)
HARNESS_API_KEY	Có*	--	Mã truy cập cá nhân Harness hoặc mã tài khoản dịch vụ. Bắt buộc trong chế độ single-user. KHÔNG được đặt trong chế độ multi-user hoặc oauth, nơi mỗi phiên mang thông tin xác thực riêng
HARNESS_ACCOUNT_ID	Không	(từ PAT/SAT)	Định danh tài khoản Harness. Tự động trích xuất từ mã PAT/SAT trong chế độ một người dùng; phiên nhiều người dùng có thể cung cấp mã riêng qua x-harness-account-id khi khóa API không nhúng định danh
HARNESS_BASE_URL	Không	https://app.harness.io (https://mcp.harness.io/cli trong chế độ OAuth)	URL cơ sở API/Giao diện Harness. Chế độ OAuth định tuyến qua proxy MCP /cli được lưu trữ theo mặc định; các chế độ khác sử dụng trực tiếp API SaaS Harness
HARNESS_MCP_OAUTH_ISSUER	Không	https://id.harness.io/idp/realms/HarnessIDP	Nhà phát hành HarnessID khớp chính xác với xác nhận quyền sở hữu iss của mã truy cập
HARNESS_MCP_OAUTH_RESOURCE	Không	https://mcp.harness.io/mcp	URL MCP chuẩn công khai được xuất bản dưới dạng định danh tài nguyên RFC 9728
HARNESS_MCP_OAUTH_JWKS_URI	Không	<issuer>/protocol/openid-connect/certs	Điểm cuối JWKS HarnessID dùng để xác thực chữ ký mã truy cập RS256
HARNESS_MCP_OAUTH_CLIENT_ID	Không	mcp-client	Máy khách HarnessID mà mã truy cập phải được cấp cho, được kiểm tra với xác nhận quyền sở hữu azp của mã
HARNESS_MCP_OAUTH_ACCOUNT_CLAIM	Không	account_id	Xác nhận quyền sở hữu mã truy cập mang ID tài khoản Harness, được điền bởi phạm vi organization của HarnessID
HARNESS_MCP_OAUTH_SCOPES	Không	openid profile email organization	Các phạm vi phân tách bằng dấu cách được quảng cáo trong siêu dữ liệu tài nguyên được bảo vệ RFC 9728
HARNESS_FME_API_KEY	Không	--	Thông tin xác thực FME/Split Admin tùy chọn cho một người dùng/tự lưu trữ dùng cho tài nguyên fme_ trong chế độ kế thừa (workspace_id) chỉ. FME kế thừa không khả dụng trong chế độ OAuth nên mã HarnessID không bao giờ được gửi đến api.split.io; sử dụng phạm vi org_id+project_id gốc Harness thay thế. Không được đặt trong chế độ multi-user hoặc oauth
HARNESS_FME_BASE_URL	Không	https://api.split.io	URL cơ sở API Admin Split/FME dùng bởi tài nguyên fme_ trong chế độ kế thừa (workspace_id) chỉ. URL HTTP yêu cầu HARNESS_ALLOW_HTTP=true cho phát triển cục bộ. Chế độ gốc Harness (org_id+project_id) bỏ qua giá trị này và sử dụng HARNESS_API_KEY/HARNESS_BASE_URL tiêu chuẩn thay thế
HARNESS_ORG	Không	--	ID tổ chức. Được dùng khi org_id không được chỉ định cho mỗi lần gọi công cụ. Nếu bỏ qua, org_id phải được cung cấp rõ ràng. Tác nhân cũng có thể khám phá tổ chức động qua harness_list(resource_type="organization")
HARNESS_PROJECT	Không	--	ID dự án. Được dùng khi project_id không được chỉ định cho mỗi lần gọi công cụ. Tác nhân cũng có thể khám phá dự án động qua harness_list(resource_type="project")
HARNESS_API_TIMEOUT_MS	Không	30000	Thời gian chờ yêu cầu HTTP tính bằng mili giây
HARNESS_MAX_RETRIES	Không	3	Số lần thử lại cho lỗi tạm thời (429, 5xx)
HARNESS_MAX_BODY_SIZE_MB	Không	10	Kích thước tối đa thân yêu cầu HTTP tính bằng MB cho truyền tải http
HARNESS_RATE_LIMIT_RPS	Không	10	Giới hạn yêu cầu phía máy khách (yêu cầu mỗi giây) đến API Harness
LOG_LEVEL	Không	info	Mức chi tiết nhật ký: debug, info, warn, error
HARNESS_TOOLSETS	Không	(mặc định)	Danh sách bộ công cụ phân tách bằng dấu phẩy. Trống tải bộ công cụ mặc định. Hỗ trợ +name để bao gồm rõ ràng bộ công cụ chọn tham gia và -name để loại bỏ mặc định (xem Lọc bộ công cụ)
HARNESS_READ_ONLY	Không	false	Chặn tất cả thao tác thay đổi (tạo, cập nhật, xóa, thực thi). Chỉ cho phép danh sách và lấy. Hữu ích cho môi trường dùng chung/demo
HARNESS_AUTO_APPROVE_RISK	Không	none	Ngưỡng tự động phê duyệt dựa trên rủi ro cho quy trình tự động. Thao tác ở mức rủi ro này hoặc thấp hơn tiến hành mà không cần xác nhận. Giá trị: none, low_write, medium_write, high_write, all. Xem Elicitation
HARNESS_SKIP_ELICITATION	Không	false	Không dùng nữa — sử dụng HARNESS_AUTO_APPROVE_RISK=all thay thế. Giữ để tương thích ngược
HARNESS_ALLOW_HTTP	Không	false	Cho phép HARNESS_BASE_URL không phải HTTPS. Theo mặc định, máy chủ thực thi HTTPS vì bảo mật. Đặt thành true chỉ cho phát triển cục bộ với phiên bản Harness không TLS
HARNESS_PIPELINE_VERSION	Không	0	(Alpha) Phiên bản YAML Pipeline. 0 tải loại tài nguyên pipeline và loại trừ pipeline_v1; 1 tải pipeline_v1 và loại trừ pipeline. Phiên HTTP có thể ghi đè tại thời điểm khởi tạo với x-harness-pipeline-version: 0 hoặc 1
HARNESS_MCP_ALLOWED_HOSTS	Không	--	Danh sách tên máy chủ phân tách bằng dấu phẩy được phép bởi xác thực tiêu đề Host của truyền tải HTTP. mcp.harness.io được phép theo mặc định cho liên kết localhost; thêm proxy/miền tùy chỉnh tại đây
HARNESS_MCP_AUTH_TOKEN	Không	--	Mã Bearer tĩnh bắt buộc trên các tuyến HTTP /mcp khi được đặt. Bắt buộc theo mặc định cho liên kết một người dùng và nhiều người dùng không loopback. Phải bỏ đặt trong chế độ oauth
HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP	Không	false	Cho phép rõ ràng truyền tải HTTP không xác thực trên liên kết không loopback. Chỉ dùng phía sau một điều khiển xác thực khác
HARNESS_MCP_TRUST_PROXY	Không	0	Số bước nhảy proxy ngược / cân bằng tải để tin cậy cho phân giải IP máy khách (Express trust proxy). Đặt thành số proxy phía trước máy chủ để giới hạn tốc độ theo IP dựa trên máy khách thực thay vì peer socket proxy
HARNESS_MCP_LOG_FILE	Không	~/.claude/harness-mcp.log	Tệp dùng cho chẩn đoán ngắt kết nối/sự cố stdio khi stderr có thể không còn khả dụng
HARNESS_LOG_UNSAFE_BODIES	Không	false	Bao gồm thân yêu cầu/phản hồi thô trong nhật ký. Tắt theo mặc định vì thân có thể chứa bí mật; chỉ bật để gỡ lỗi cục bộ
HARNESS_AUDIT_FILE	Không	--	Thêm sự kiện kiểm toán vào tệp JSON phân tách dòng để thu thập cục bộ bền vững
HARNESS_AUDIT_WEBHOOK_URL	Không	--	Điểm cuối HTTPS nhận sự kiện kiểm toán theo lô. URL HTTP yêu cầu HARNESS_ALLOW_HTTP=true cho phát triển cục bộ
HARNESS_AUDIT_WEBHOOK_TOKEN	Không	--	Mã Bearer tùy chọn gửi đến webhook kiểm toán
HARNESS_AUDIT_WEBHOOK_BATCH_SIZE	Không	10	Số sự kiện kiểm toán để gộp lô trước khi xả webhook
HARNESS_AUDIT_WEBHOOK_FLUSH_MS	Không	5000	Thời gian tối đa để giữ các sự kiện kiểm toán trước khi webhook xả dữ liệu
OTEL_EXPORTER_OTLP_ENDPOINT	Không	--	Bật các span kiểm toán OpenTelemetry khi các gói OpenTelemetry tùy chọn được cài đặt
HARNESS_SEARCH_PROVIDER	Không	local	Backend tìm kiếm ngữ nghĩa: local (nhúng ONNX trong tiến trình, mặc định), remote (dịch vụ tìm kiếm bên ngoài qua HTTP, bắt buộc cho chế độ đa người dùng), hoặc none (vô hiệu hóa tìm kiếm ngữ nghĩa, chỉ dùng scatter-gather từ khóa). Sử dụng none trong môi trường cách ly mạng hoặc khi không mong muốn tải mô hình khi khởi động
HARNESS_SEARCH_SERVICE_URL	Không	--	URL cơ sở của dịch vụ tìm kiếm từ xa khi HARNESS_SEARCH_PROVIDER=remote (ví dụ: http://search-svc:8080). Bắt buộc khi sử dụng nhà cung cấp remote
HARNESS_SEARCH_SERVICE_HEADERS	Không	--	Đối tượng JSON chứa các header được gửi kèm mọi yêu cầu đến dịch vụ tìm kiếm từ xa. Hỗ trợ mọi lược đồ xác thực: {"Authorization":"Bearer tok"}, {"x-api-key":"key"}, hoặc nhiều header nội bộ giữa các dịch vụ
HARNESS_HF_CACHE_DIR	Không	/tmp/hf-cache	Thư mục cho bộ nhớ cache mô hình @huggingface/transformers được sử dụng bởi nhà cung cấp tìm kiếm local. Hình ảnh Docker đã nhúng sẵn mô hình vào /app/.cache/hf để tránh tải xuống khi chạy. Đặt thành đường dẫn ổ đĩa bền vững trong các triển khai sản xuất
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	Không	3	Số lượng tải xuống khối nhật ký đồng thời tối đa do harness_diagnose phát hành khi lấy nhật ký cho các bước thất bại. Chỉ tăng nếu độ trễ chẩn đoán bị chi phối bởi thời gian tường lửa tải nhật ký và pod có dư bộ nhớ

Tìm kiếm ngữ nghĩa

harness_search sử dụng định tuyến ngữ nghĩa để thu hẹp các lệnh gọi API scatter-gather trước khi phân phối đến Harness. Có ba nhà cung cấp tìm kiếm:

Nhà cung cấp	Khi nào sử dụng
local (mặc định)	Chế độ stdio một người dùng. Chạy all-MiniLM-L6-v2 trong tiến trình thông qua @huggingface/transformers. Tải mô hình ~23 MB ở lần sử dụng đầu tiên; các lần khởi động sau sử dụng bộ nhớ đệm.
remote	Chế độ HTTP nhiều người dùng (do Harness lưu trữ). Ủy quyền nhúng và truy xuất cho một dịch vụ tìm kiếm bên ngoài. Cách ly đối tượng thuê được thực thi thông qua tenant_id — kiến thức/tài liệu tĩnh sử dụng global, dữ liệu thực thể theo tài khoản sử dụng ID tài khoản.
none	Tắt hoàn toàn tìm kiếm ngữ nghĩa; quay lại scatter-gather theo từ khóa trên tất cả các loại tài nguyên.

Cấu hình nhà cung cấp từ xa:

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

Kiểm thử nhà cung cấp từ xa cục bộ với dịch vụ stub đi kèm (không có phụ thuộc bên ngoài):

# 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) triển khai cùng hợp đồng /v1/health, /v1/ingest và /v1/search như dịch vụ tìm kiếm sản xuất. Nó sử dụng một phương pháp nhúng bag-of-chars đơn giản nên không cần tải mô hình — kết quả hợp lý về mặt ngữ nghĩa nhưng không đạt chất lượng sản xuất.

Thực thi HTTPS

HARNESS_BASE_URL phải sử dụng HTTPS theo mặc định. Nếu bạn đặt URL không phải HTTPS (ví dụ: http://localhost:8080), máy chủ sẽ từ chối khởi động với:

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

Ghi nhật ký kiểm toán

Tất cả các thao tác API Harness được điều phối qua registry (list, get, create, update, delete và execute) phát ra các sự kiện kiểm toán có cấu trúc khi các sink kiểm toán được cấu hình. Các sự kiện thay đổi bao gồm đường dẫn xác nhận được sử dụng bởi quá trình elicitation hoặc tự động phê duyệt khi có ngữ cảnh xác nhận; các sự kiện đọc hiện bỏ qua siêu dữ liệu xác nhận. Các công cụ khám phá siêu dữ liệu và lược đồ cục bộ bỏ qua registry, chẳng hạn như harness_describe và harness_schema, không nằm trong luồng kiểm toán này. Một sink stderr được đăng ký theo mặc định nhưng đi qua logger thông thường và tuân theo LOG_LEVEL; cấu hình sink tệp hoặc webhook để thu thập kiểm toán bền vững:

• HARNESS_AUDIT_FILE nối thêm các sự kiện JSON phân tách bằng dòng mới để thu thập cục bộ.
• HARNESS_AUDIT_WEBHOOK_URL đăng các lô { "events": [...] } đến một webhook HTTPS, tùy chọn với HARNESS_AUDIT_WEBHOOK_TOKEN. Các lô thất bại được đưa lại vào hàng đợi với dung lượng giới hạn và cuối cùng bị loại bỏ với cảnh báo thay vì chặn thực thi công cụ.
• OTEL_EXPORTER_OTLP_ENDPOINT bật các span kiểm toán khi các phụ thuộc ngang hàng OpenTelemetry tùy chọn được cài đặt. Sink tái sử dụng một nhà cung cấp tracer hiện có khi được đăng ký, nếu không nó sẽ khởi tạo một bộ xuất OTLP độc lập.

Mỗi sự kiện bao gồm tên công cụ, loại tài nguyên, thao tác, định danh, dấu thời gian, mức rủi ro, kết quả, phương thức/đường dẫn HTTP, thời lượng và phương thức xác nhận khi áp dụng. Các sink kiểm toán là telemetry nỗ lực tốt nhất; các vấn đề phân phối được ghi lại và không bao giờ phát lại hoặc thay đổi thao tác API Harness bên dưới. Để biết chi tiết thiết lập OTel và thuộc tính span, xem specs/005-otel-audit-sink.md.

Tham chiếu công cụ

Máy chủ hiển thị 11 công cụ MCP. Hầu hết các công cụ API chấp nhận org_id và project_id làm ghi đè tùy chọn — nếu bỏ qua, chúng sẽ quay lại HARNESS_ORG và HARNESS_PROJECT. harness_describe chỉ là siêu dữ liệu cục bộ và không sử dụng phạm vi org/project.

Hỗ trợ URL: Hầu hết các công cụ hướng API chấp nhận tham số url — dán URL giao diện Harness và máy chủ tự động trích xuất org, project, loại tài nguyên, ID tài nguyên, ID pipeline và ID thực thi. harness_describe không chấp nhận url.

Hỗ trợ phạm vi: Các loại tài nguyên có biến thể account/org/project hiển thị supportedScopes trong harness_describe. Truyền resource_scope khi bạn cần một cấp độ cụ thể:

• resource_scope: "account" chỉ gửi accountIdentifier.
• resource_scope: "org" gửi accountIdentifier và orgIdentifier.
• resource_scope: "project" gửi định danh account, org và project.

Các tài nguyên đa phạm vi hiện tại bao gồm connector, service, environment, infrastructure, secret, file_store, template, policy và policy_set. Nếu resource_scope bị bỏ qua, registry sử dụng phạm vi mặc định của tài nguyên và các mặc định đã cấu hình, ngoại trừ các tài nguyên được đánh dấu là phạm vi tùy chọn có thể bỏ qua org/project trừ khi được truyền rõ ràng. URL Harness cũng có thể tự động đặt phạm vi khi đường dẫn chứa ngữ cảnh cấp tài khoản hoặc cấp project.

Đầu ra có cấu trúc: Mọi công cụ khai báo outputSchema MCP. harness_list chuẩn hóa các phản hồi Harness dạng danh sách thành nội dung có cấu trúc dạng đối tượng để các máy khách nghiêm ngặt có thể xác thực: các mảng cấp cao nhất trở thành { "items": [...], "total": <count>, "page": <page> }, và các khóa bọc phổ biến như content, data, body, objects hoặc features được nâng lên items khi cần. Phản hồi văn bản vẫn chứa tải trọng JSON nhỏ gọn được trả về cho tất cả các máy khách.

Công cụ	Mô tả
harness_describe	Khám phá các loại tài nguyên, thao tác và trường dữ liệu có sẵn. Không gọi API — chỉ trả về siêu dữ liệu registry cục bộ.
harness_schema	Lấy định nghĩa Schema YAML/JSON chính xác và ví dụ để tạo/cập nhật tài nguyên. Schema pipeline/template được đóng gói sẵn; schema connector, environment, service, secret và infrastructure là schema thực thể nhận biết phạm vi được lấy từ snapshot đóng gói hoặc NG /yaml-schema; schema release_process và release_activity được lấy trực tiếp từ RMG /api/yamlSchema. Hỗ trợ truy cập sâu qua path.
harness_list	Liệt kê tài nguyên theo loại với bộ lọc, tìm kiếm và phân trang.
harness_get	Lấy một tài nguyên duy nhất theo định danh của nó.
harness_create	Tạo tài nguyên mới. Hỗ trợ pipeline nội tuyến và từ xa (Git-backed). Yêu cầu xác nhận từ người dùng qua elicitation.
harness_update	Cập nhật tài nguyên hiện có. Hỗ trợ pipeline nội tuyến và từ xa (Git-backed). Yêu cầu xác nhận từ người dùng qua elicitation.
harness_delete	Xóa tài nguyên. Yêu cầu xác nhận từ người dùng qua elicitation. Hành động phá hủy.
harness_execute	Thực thi một hành động trên tài nguyên (chạy/chạy lại pipeline, nhập pipeline từ Git, bật/tắt flag, đồng bộ ứng dụng). Yêu cầu xác nhận từ người dùng qua elicitation. Đối với pipeline runs, sử dụng quy trình runtime-input bên dưới (hỗ trợ khai triển rút gọn branch/tag/pr_number/commit_sha).
harness_search	Tìm kiếm trên các loại tài nguyên Harness với một truy vấn duy nhất. Sử dụng định tuyến ngữ nghĩa (embedding ONNX all-MiniLM-L6-v2 cục bộ, 384 chiều) để dự đoán các loại tài nguyên liên quan từ kho ngữ liệu knowledge được lập chỉ mục khi khởi động — thường thu hẹp từ ~163 loại xuống 1–8 trước khi scatter-gather. Dự phòng sang scatter-gather từ khóa toàn phần khi độ tin cậy ngữ nghĩa thấp. Phản hồi bao gồm semantic_routed và types_skipped khi định tuyến được kích hoạt. Xem docs/search-guidelines.md để biết cách làm cho các loại tài nguyên mới có thể khám phá được.
harness_diagnose	Chẩn đoán tài nguyên pipeline, connector, delegate và gitops_application (bí danh: execution -> pipeline, gitops_app -> gitops_application). Đối với pipeline, trả về thời gian stage/step và chi tiết lỗi; đối với connector/delegate/ứng dụng GitOps, trả về tín hiệu sức khỏe và khắc phục sự cố có mục tiêu.
harness_status	Lấy bảng điều khiển sức khỏe dự án theo thời gian thực — các lần thực thi gần đây, tỷ lệ lỗi và liên kết sâu.

Quy trình tra cứu Schema

Sử dụng harness_schema trước khi tạo hoặc cập nhật tài nguyên YAML-backed để agent có thể sao chép chính xác tên trường và ràng buộc thay vì đoán từ mô tả.

• Schema đóng gói bao gồm pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1 và agent-pipeline.
• Schema thực thể bao gồm connector, environment, service, secret và infrastructure. Chúng nhận biết phạm vi (account, org hoặc project) và yêu cầu org_id/project_id khi phạm vi đã chọn yêu cầu.
• Định nghĩa Release Management (release_process, release_activity) lấy JSON Schema trực tiếp từ RMG /api/yamlSchema (không đóng gói). Truyền scope, org_id và project_id khi phạm vi ở cấp org hoặc project.
• Snapshot thực thể được lưu kèm được sử dụng trước khi chúng khớp với tài khoản runtime; nếu không, công cụ sẽ dự phòng sang API NG /yaml-schema của Harness và lưu kết quả vào bộ nhớ đệm.
• Bỏ qua path để có tóm tắt trường/phần, sau đó truyền path phân tách bằng dấu chấm để kiểm tra định nghĩa lồng nhau.

Ví dụ:

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

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

Người duy trì có thể làm mới snapshot thực thể được lưu kèm bằng pnpm sync-entity-schemas khi schema YAML thực thể Harness thay đổi.

Ví dụ về công cụ

Khám phá các tài nguyên có sẵn:

{ "resource_type": "pipeline" }

Liệt kê tổ chức trong tài khoản:

{ "resource_type": "organization" }

Liệt kê dự án trong một tổ chức:

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

Liệt kê pipeline trong một dự án:

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

Lấy một service cụ thể:

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

Chạy một pipeline:

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

Bật/tắt một feature flag:

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

Tìm kiếm trên tất cả các loại tài nguyên:

{ "query": "payment-service" }

Chẩn đoán một lần thực thi theo ID (chế độ tóm tắt — mặc định):

{ "execution_id": "abc123XYZ" }

Chẩn đoán từ URL Harness:

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

Chẩn đoán kết nối connector:

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

Chẩn đoán sức khỏe delegate:

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

Chẩn đoán ứng dụng GitOps (với các tùy chọn):

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

Lấy báo cáo thực thi mới nhất cho một pipeline:

{ "pipeline_id": "my-pipeline" }

Chế độ chẩn đoán đầy đủ với YAML và log bước lỗi:

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

Chế độ tóm tắt với log được bật (kết hợp tốt nhất):

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

Lấy trạng thái sức khỏe dự án:

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

Liệt kê schema cơ sở dữ liệu được lọc theo loại di trú:

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

Liệt kê phiên bản cơ sở dữ liệu cho một schema:

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

Lấy pipeline tác giả LLM đã giải quyết cho một schema và phiên bản:

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

Liệt kê tên đối tượng snapshot (ví dụ: bảng) cho một phiên bản schema:

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

Lấy siêu dữ liệu snapshot đầy đủ cho các đối tượng được đặt tên cụ thể:

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

Quy trình chạy Pipeline (Khuyến nghị)

Đối với pipeline v0, sử dụng trình tự này để giảm lỗi đầu vào khi thực thi:

1. Khám phá các đầu vào runtime bắt buộc

• harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
• Template trả về hiển thị các placeholder <+input> cần giá trị.

2. Chọn chiến lược đầu vào

• Biến đơn giản: truyền inputs key-value phẳng (ví dụ {"branch":"main","env":"prod"}).

• Đầu vào phức tạp/cấu trúc: sử dụng input_set_ids (khối codebase/build CI và đầu vào template lồng nhau được xử lý tốt nhất theo cách này).

• Khóa rút gọn codebase CI (chỉ cho pipeline run):

  Khóa rút gọn	Cấu trúc khai triển
  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>

• Ràng buộc: khai triển rút gọn bị bỏ qua khi inputs.build đã có sẵn (build tường minh được ưu tiên).

3. Thực thi lần chạy

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

• Đối với pipeline Git-backed có YAML cần tải từ nhánh không mặc định, truyền params.pipeline_branch (gửi đến Harness dưới dạng branch). Bộ chọn định nghĩa tường minh này được ưu tiên hơn bí danh params.branch. inputs.branch chọn độc lập nhánh codebase CI:

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

4. Tùy chọn: kết hợp cả hai

• Sử dụng input_set_ids cho hình dạng cơ sở và inputs cho các ghi đè đơn giản.

Đối với pipeline v1:

1. Lấy harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>"). Đối với pipeline Git-backed, truyền branch_name, connector_ref và repo_name qua params.
2. Sử dụng từng inputs[].details.name trả về làm khóa cấp cao nhất trong harness_execute.inputs.
3. Chạy harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}). Máy chủ bọc các giá trị này dưới gốc YAML inputs: và gửi phần thân inputs_yaml của API. Nếu các trường bắt buộc chưa được giải quyết, công cụ sẽ trả về lỗi tiền kiểm tra (pre-flight) kèm theo các khóa dự kiến và các bộ đầu vào được đề xuất. Bạn có thể kiểm tra các ánh xạ viết tắt có sẵn bằng harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands).

Thực thi Pipeline Động

Sử dụng pipeline_dynamic_execution.run khi một agent hoặc hệ thống bên ngoài tạo toàn bộ YAML pipeline v0 tại thời điểm chạy và cần chạy nó trên một pipeline shell Harness hiện có. Đây không phải là sự thay thế cho pipeline.run thông thường: pipeline v0 đã lưu phải tồn tại, các cài đặt Allow Dynamic Execution ở cấp tài khoản và cấp pipeline phải được bật, và người gọi cần quyền Edit và Execute trên pipeline.

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

Các ràng buộc:

• body phải là một đối tượng có trường yaml. Các chuỗi thô bị từ chối bởi schema harness_execute công khai.
• body.yaml có thể là một chuỗi YAML hoặc một đối tượng pipeline JSON; JSON được tuần tự hóa thành YAML trước khi gửi yêu cầu.
• Các placeholder <+input> thời gian chạy không được API này giải quyết. Hãy gửi YAML đã được giải quyết đầy đủ.
• Input sets, thực thi giai đoạn chọn lọc, retry và triggers không được hỗ trợ bởi endpoint thực thi động.
• Hành động là high_write và sử dụng đường dẫn xác nhận/tự động phê duyệt thông thường. Phản hồi chiếu envelope API tới { "execution_id": "...", "status": "..." } và bao gồm liên kết thực thi openInHarness khi có dữ liệu phạm vi.

Nếu Harness từ chối lần chạy vì không được bật, hãy kiểm tra cả cài đặt Allow Dynamic Execution ở cấp tài khoản và công tắc ở cấp pipeline trong Pipeline -> Advanced Options -> Dynamic Execution Settings.

Điều tra Đầu vào Thực thi

Sử dụng execution_inputs sau một lần chạy để kiểm tra YAML đầu vào đã hợp nhất tạo ra một thực thi cụ thể. Điều này hữu ích khi lỗi phụ thuộc vào việc hợp nhất input set, các nhánh input set được hỗ trợ bởi Git, hoặc các giá trị trigger/thời gian chạy khó tái tạo chỉ từ trang thực thi.

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

Phản hồi get được chiếu tới:

• executionId - ID thực thi kế hoạch từ resource_id.
• inputSetYaml - YAML đầu vào thời gian chạy đã hợp nhất được sử dụng cho lần chạy, hoặc null.
• inputSetTemplateYaml - mẫu đầu vào tại thời điểm thực thi, hoặc null.
• resolvedYaml - YAML đã giải quyết biểu thức khi resolve_expressions=true, nếu không thì thường là null.
• inputSetDetails - các input set đã lưu đóng góp dưới dạng cặp { identifier, name }.
• inputSetBranchName - nhánh nguồn cho các input set được hỗ trợ bởi Git, hoặc null.

execution_inputs chỉ dành cho get và có rủi ro đọc. Nếu resolve_expressions bị bỏ qua, máy chủ sẽ bỏ qua các tham số truy vấn API và Harness sử dụng chế độ giải quyết UNKNOWN mặc định của nó.

Chế độ Chờ Thực thi Pipeline

Đối với pipeline.run, pipeline.retry và pipeline_v1.run, hãy truyền wait: true để máy chủ thăm dò cho đến khi thực thi đạt trạng thái cuối. Điều này giữ cho việc khởi chạy pipeline và kiểm tra trạng thái trong một lần gọi công cụ thay vì yêu cầu client hoặc LLM chạy một vòng lặp thăm dò.

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

Hành vi chế độ chờ:

• Thời gian chờ mặc định là 600 giây; phạm vi cho phép từ 10 giây đến 7200 giây.
• Khoảng thời gian thăm dò ban đầu mặc định là 3 giây, lùi lại theo hệ số 1.5x và giới hạn tối đa ở 30 giây.
• Khi thành công hoặc thất bại, phản hồi bao gồm các trường như execution_id, execution_status, execution_terminal, execution_elapsed_ms và execution_poll_count.
• Nếu hết thời gian chờ, trigger ban đầu vẫn thành công; phản hồi bao gồm execution_timed_out: true và _wait.hint với trạng thái quan sát cuối cùng.
• Nếu thăm dò thất bại sau khi trigger thành công, phản hồi bao gồm _wait.error và gợi ý kiểm tra lại. Không chạy lại pipeline một cách mù quáng trừ khi bạn đã xác nhận rằng lần thực thi đầu tiên không đang chạy.
• Các trạng thái cuối thất bại bao gồm _diagnose_hint trỏ tới harness_diagnose(resource_type="execution", options={execution_id: "..."}).

Yêu cầu AI DevOps Agent tạo một pipeline:

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

Cập nhật một service qua ngôn ngữ tự nhiên:

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

Chế độ Lưu trữ Pipeline

Các pipeline Harness có thể được lưu trữ theo ba cách:

Chế độ	Mô tả	Khi nào sử dụng
Inline	YAML pipeline được lưu trong Harness	Mặc định. Thiết lập đơn giản nhất, không yêu cầu Git.
Remote (External Git)	YAML pipeline được lưu trong GitHub, GitLab, Bitbucket, v.v.	Các nhóm sử dụng pipeline-as-code được hỗ trợ bởi Git với nhà cung cấp bên ngoài.
Remote (Harness Code)	YAML pipeline được lưu trong kho lưu trữ Harness Code	Các nhóm sử dụng dịch vụ lưu trữ Git tích hợp của Harness.

Tạo một pipeline inline (mặc định):

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

Tạo một pipeline remote (External Git — ví dụ: 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"
  }
}

Tạo một pipeline remote (Harness Code — không cần connector):

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

Cập nhật một pipeline remote:

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

Nhập một pipeline từ kho Git bên ngoài:

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

Nhập một pipeline từ kho 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"
  }
}

Tạo một connector:

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

Xóa một trigger:

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

Liệt kê các input set cho một pipeline:

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

Lấy một input set cụ thể:

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

Tạo một input set:

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

Cập nhật một input set:

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

Xóa một input set:

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

Các Loại Tài nguyên

255 loại tài nguyên được tổ chức trong 41 bộ công cụ. Mỗi loại tài nguyên hỗ trợ một tập con các thao tác CRUD và các hành động thực thi tùy chọn.

Nền tảng

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
organization	x	x	x	x	x
project	x	x	x	x	x

Pipelines

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
pipeline	x	x	x	x	x	run, retry
pipeline_v1 (Alpha)	x	x	x	x	x	run
pipeline_dynamic_execution						run
execution	x	x				interrupt
execution_inputs		x
trigger	x	x	x	x	x
pipeline_summary		x
input_set	x	x	x	x	x
runtime_input_template		x
runtime_input_template_v1		x
pipeline_resolved_yaml		x
approval_instance	x					approve, reject

Cả hai loại tài nguyên YAML pipeline đều có sẵn khi bộ công cụ pipelines được bật. HARNESS_PIPELINE_VERSION và tiêu đề khởi tạo HTTP x-harness-pipeline-version chọn tùy chọn phiên bản mặc định; chúng không ẩn phiên bản khác.

AI Agents

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
agent	x	x	x	x	x
agent_run	x

Services

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
service	x	x	x	x	x

Environments

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
environment	x	x	x	x	x	move_configs

Connectors

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
connector	x	x	x	x	x	test_connection
connector_catalogue	x

Cơ sở hạ tầng

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
infrastructure	x	x	x	x	x	move_configs

Secrets

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
secret	x	x

Nhật ký Thực thi

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
execution_log		x

Dấu vết Kiểm toán

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
audit_event	x	x

Delegates

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
delegate	x	x
delegate_token	x	x	x		x	revoke, get_delegates

Kho lưu trữ Mã

Loại Tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động Thực thi
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

Việc tạo commit cam kết một hoặc nhiều hành động tệp trực tiếp thông qua API Harness Code mà không cần clone. Truyền body.title, body.branch và body.actions; mỗi hành động là CREATE, UPDATE, DELETE hoặc MOVE, và UPDATE yêu cầu blob SHA hiện tại.

Danh sách file_content trả về mọi đường dẫn tại một ref; get trả về nội dung tệp hoặc thư mục (bỏ qua hoặc truyền path trống cho thư mục gốc của kho; các đường dẫn lồng nhau giữ dấu gạch chéo). Bỏ qua git_ref để sử dụng nhánh mặc định của kho lưu trữ — không đoán main.

Cơ quan đăng ký Artifact

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
registry	x	x
artifact	x
artifact_version	x
artifact_file	x

Kho lưu trữ tệp

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
file_store	x	x	x	x	x	list_children

file_store quản lý các tệp và thư mục trong Kho lưu trữ tệp Harness thông qua các công cụ chung. Nó hỗ trợ phạm vi tài khoản, tổ chức và dự án; truyền resource_scope="account"|"org"|"project" hoặc dán URL Kho lưu trữ tệp Harness để máy chủ có thể suy ra phạm vi và ID.

Các lệnh gọi phổ biến:

# 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"})

Các ràng buộc về nội dung multipart:

• Tạo/cập nhật chấp nhận JSON body, sau đó chuyển đổi thành multipart/form-data cho /ng/api/file-store.
• name, type (FILE hoặc FOLDER) và parent_identifier là bắt buộc; chỉ sử dụng "Root" theo nghĩa đen cho thư mục gốc của phạm vi đã chọn.
• Tạo FILE yêu cầu chính xác một trong content (chuỗi UTF-8) hoặc content_base64 (base64 hợp lệ không rỗng). Cập nhật FILE có thể bỏ qua nội dung để cập nhật chỉ siêu dữ liệu hoặc cung cấp chính xác một trường nội dung để thay thế nội dung.
• Tạo/cập nhật FOLDER phải bỏ qua content và content_base64.
• file_usage tùy chọn phải là MANIFEST_FILE, CONFIG hoặc SCRIPT; siêu dữ liệu vô hướng tùy chọn như description, mime_type, path và tags phải là chuỗi.
• Nội dung tải lên được giới hạn ở 100 MB. Các lời nhắc xác nhận sẽ ẩn bản xem trước content, content_base64 và contentBase64 trước khi hỏi.

list_children chấp nhận dạng viết tắt (resource_id cộng params.folder_name hoặc params.file_store_id/params.folder_identifier cộng params.folder_name) hoặc FileStoreNode body đầy đủ với identifier, name và type: "FOLDER". Nội dung đầy đủ sử dụng parentIdentifier dạng camelCase của Harness; dạng viết tắt có thể sử dụng params.parent_identifier.

Mẫu

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
template	x	x	x	x	x

Các thao tác mẫu sử dụng đường dẫn dịch vụ Mẫu Harness (/template/api/templates...). Tạo và cập nhật yêu cầu chuỗi YAML mẫu đầy đủ trong body.template_yaml hoặc body.yaml; version_label nhắm đến một phiên bản cụ thể để cập nhật/xóa, trong khi xóa mà không có version_label sẽ xóa tất cả các phiên bản.

Bảng điều khiển

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
dashboard	x	x
dashboard_data		x

DevOps cơ sở dữ liệu

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
database_schema	x	x	x	x	x
database_instance	x	x	x	x	x
database_snapshot_object	x	x
database_llm_authoring_pipeline		x

Quản lý cơ sở hạ tầng dạng mã (IaCM)

Các tài nguyên IaCM được bật theo mặc định và chủ yếu có phạm vi dự án. Bắt đầu với iacm_workspace để tìm mã định danh không gian làm việc, sau đó sử dụng workspace_id đó cho các tài nguyên không gian làm việc, chi phí và khác biệt hoạt động. Sử dụng iacm_variable_set cho các bộ biến có thể tái sử dụng ở phạm vi tài khoản, tổ chức hoặc dự án. Sổ đăng ký nhà cung cấp có phạm vi tài khoản.

iacm_module trải dài qua phạm vi tài khoản, tổ chức và dự án. Nó mặc định là sổ đăng ký tài khoản; mọi thao tác (danh sách, lấy, tạo, cập nhật) đều gửi cùng tham số truy vấn scope_org / scope_project, vì vậy một mô-đun bạn tạo có thể được khám phá ở phạm vi bạn đã tạo. Chọn phạm vi bằng resource_scope="account" | "org" | "project" cộng org_id/project_id. Phạm vi là tùy chọn: khi bỏ qua resource_scope, org_id/project_id chỉ áp dụng nếu bạn truyền chúng một cách tường minh — các mặc định HARNESS_ORG/HARNESS_PROJECT đã cấu hình không được áp dụng, vì vậy cấu hình dự án xung quanh không thể âm thầm đăng ký mô-đun tài khoản dưới một dự án. Các trường org/project của chính nội dung mô-đun định vị trình kết nối Git của nó và không liên quan đến phạm vi hiển thị này.

Tạo/cập nhật iacm_workspace chỉ trả về { policy_evaluation } — hãy theo dõi bằng harness_get để tìm nạp không gian làm việc. Tạo/cập nhật iacm_variable_set và iacm_module trả về chính tài nguyên đó. Tạo iacm_provider chỉ trả về { id } — hãy theo dõi bằng harness_get; cập nhật chỉ theo hướng phiên bản (POST/PUT /providers/{id}/version) — không có PUT siêu dữ liệu. Ghi phiên bản có thể trả về nội dung trống; HarnessClient chuẩn hóa điều đó thành { status: "SUCCESS", message: "No content" }.

Cập nhật bộ biến là HTTP PUT với các bộ sưu tập thay thế toàn bộ — luôn harness_get trước, sau đó PUT toàn bộ nội dung mong muốn (terraform_variables / environment_variables là bắt buộc khi cập nhật; bỏ qua/trống sẽ xóa trình kết nối và tệp biến). Cập nhật mô-đun cũng là PUT — ưu tiên lấy-rồi-đặt cho các trường tùy chọn. Ghi là medium_write và yêu cầu xác nhận (hỏi hoặc confirm: true).

RBAC bộ biến và sổ đăng ký nhà cung cấp (iac_variableset_*, iac_providerregistry_*) hiện đang ở trạng thái Thử nghiệm trong Harness — kiểm tra truy cập luôn cho phép cho đến khi iac-server kích hoạt thực thi. RBAC sổ đăng ký mô-đun (iac_registry_view / iac_registry_edit) đang Hoạt động và có thể thực thi. MCP luôn chuyển tiếp PAT/SAT của người gọi không thay đổi.

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
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

Quy trình làm việc điển hình:

1. harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") để tìm không gian làm việc.
2. harness_create / harness_update trên iacm_workspace để tạo từ đầu hoặc từ mẫu (associated_template) hoặc cập nhật không gian làm việc hiện có — phản hồi chỉ là { policy_evaluation }.
3. harness_get(resource_type="iacm_workspace", workspace_id="...") để tìm nạp không gian làm việc đã tạo/cập nhật.
4. harness_list / harness_create / harness_update trên iacm_variable_set (tùy chọn với resource_scope) cho các bộ biến Terraform/env có thể tái sử dụng — phản hồi là tài nguyên VariableSet.
5. harness_list / harness_create / harness_update trên iacm_module cho sổ đăng ký mô-đun (name + system bắt buộc; thêm resource_scope với org_id/project_id cho mô-đun có phạm vi tổ chức hoặc dự án) — phản hồi là tài nguyên mô-đun.
6. harness_list / harness_create / harness_update trên iacm_provider cho sổ đăng ký nhà cung cấp tài khoản (body.type bắt buộc để tạo; tạo chỉ trả về { id } — sau đó harness_get; cập nhật chỉ tạo/cập nhật phiên bản) — cập nhật phiên bản có thể trả về thành công trống.
7. harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") để kiểm tra tài nguyên Terraform, đầu ra và nguồn dữ liệu.
8. harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") để xem lại các mục chi phí theo từng lần thực thi.
9. harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") để kiểm tra khác biệt tài nguyên trước/sau cho hoạt động plan, apply hoặc destroy.

Phản hồi danh sách IaCM hiển thị page_count dưới dạng số lượng cho trang hiện tại chỉ (ngoại trừ iacm_variable_set, không được phân trang). Khi has_more là true, hãy tiếp tục yêu cầu trang tiếp theo dựa trên 1 và cộng số lượng trang nếu bạn cần tổng.

Cổng thông tin nhà phát triển nội bộ (IDP)

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
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

Yêu cầu kéo

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
pull_request	x	x	x	x		close, merge
pr_reviewer	x		x			submit_review
pr_comment			x	x	x
pr_check	x
pr_activity	x

Sử dụng harness_execute(resource_type="pull_request", action="close", ...) cho thao tác đóng tường minh. harness_update cũng chấp nhận body.state (open hoặc closed) và định tuyến các thay đổi trạng thái đến điểm cuối trạng thái PR Harness Code chuyên dụng; gửi chỉnh sửa tiêu đề/mô tả trong một lệnh gọi cập nhật riêng.

Sử dụng harness_list(resource_type="pr_activity", filters={type: ["comment", "code-comment"]}, ...) để đọc bình luận PR. Sử dụng pr_comment cho các thao tác ghi bình luận.

Quản lý phát hành

Các tài nguyên Quản lý phát hành (RMG) được bật theo mặc định. Các tài nguyên định nghĩa (release_process, release_activity) hỗ trợ danh sách/lấy/tạo/cập nhật/xóa với body.yaml; gọi harness_schema(resource_type="release_process"|"release_activity") trước khi tạo/cập nhật. Các tài nguyên thực thi giám sát các bản phát hành đang chạy — hầu hết các thao tác danh sách yêu cầu release_id (UUID từ harness_list resource_type=release hoặc slug URL giao diện người dùng như identifier-1.0.0-abc). Dán URL phát hành RMG vào harness_list để tự động điền release_id.

Các lệnh gọi RMG sử dụng ${HARNESS_BASE_URL}/gateway/rmg với phạm vi tài khoản qua tiêu đề Harness-Account. Phạm vi tổ chức/dự án sử dụng phạm vi dựa trên tiêu đề khi org_id/project_id được cung cấp. release_execution_phase chỉ là danh sách — sử dụng trường identifier của từng mục giai đoạn làm params.phase_identifier khi gọi harness_get trên các tài nguyên đầu vào/đầu ra giai đoạn (không gọi harness_get trên chính release_execution_phase). Lọc danh sách phát hành status được áp dụng phía máy khách chỉ trên trang hiện tại; tiếp tục phân trang với cùng bộ lọc khi kết quả có thể trải qua nhiều trang.

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
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

Quy trình làm việc điển hình:

1. harness_list(resource_type="release_process", org_id="...", project_id="...") để khám phá các định nghĩa quy trình điều phối.
2. harness_schema(resource_type="release_process") (hoặc release_activity) trước khi tạo/cập nhật; sau đó harness_create / harness_update với body.yaml.
3. harness_list(resource_type="release", org_id="...", project_id="...") để tìm các bản phát hành đang hoạt động hoặc gần đây (mặc định xem lại 30 ngày; tùy chọn filters.status, filters.search_term, filters.days_back).
4. harness_get(resource_type="release", release_id="...") để biết chi tiết bản phát hành.
5. harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) để biết trạng thái giai đoạn; cùng release_id cho release_execution_task và release_execution_activity.
6. harness_get trên release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_output, hoặc release_execution_activity_input sử dụng release_id cùng với params.phase_identifier / params.activity_identifier / activity_execution_id như được ghi chú trên từng tài nguyên.

Phong cách

Bộ công cụ vibe được bật mặc định bao phủ hợp đồng Vibe Orchestrator BFF dưới ${HARNESS_BASE_URL}/vibe/v1. Nó sử dụng kết nối Harness hiện có và tiêu đề tài khoản, mà không thêm tham số truy vấn tài khoản/tổ chức/dự án hoặc trường phạm vi vào thân yêu cầu. Nhóm đã xác thực luồng Vibe bằng xác thực khóa API Harness (PAT/SAT), vì vậy không cần cài đặt chọn tham gia cho các phiên mặc định. OpenAPI được tuyển chọn ghi lại xác thực bearer/phiên; chế độ OAuth của máy chủ chuyển tiếp mã thông báo bearer của phiên hiện tại. Các bài kiểm tra hồi quy tự động xác minh cả hai đường dẫn tiêu đề; xác thực cổng vẫn phụ thuộc vào cấu hình của môi trường đích.

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
vibe_project			x			prepare, deploy
vibe_app_lifecycle		x				events

API hỗ trợ hai đường dẫn tiếp nhận. Giữ nguyên các hình dạng yêu cầu gốc của API:

Nguồn có sẵn cho tác nhân mã hóa	Luồng API
Liên kết/trình kết nối kho lưu trữ GitHub	harness_create với resource_type="vibe_project" và body.mode cùng các trường cụ thể theo chế độ. Hợp đồng đặt tên github_link và github_connector nhưng không định nghĩa hình dạng trường URL, nhánh hoặc trình kết nối của chúng; các trường này được chuyển tiếp đến backend mà không phát minh ra ánh xạ.
Tệp ZIP	Gọi prepare với tên ứng dụng và siêu dữ liệu tệp, tải byte lên đích đã ký được trả về, sau đó gọi deploy.
Thư mục nguồn cục bộ	Tác nhân mã hóa đóng gói mã nguồn của không gian làm việc dự định thành ZIP cục bộ, sau đó làm theo luồng ZIP. Đường dẫn cục bộ hoặc ngữ cảnh hội thoại không phải là tải lên nguồn được API hỗ trợ.

Khi đóng gói một thư mục, hãy bao gồm mã nguồn, tệp kê khai, tệp khóa, cấu hình và các chỉnh sửa chưa cam kết dự định cần thiết để xây dựng nó. Loại trừ thông tin xác thực, .git, các phụ thuộc đã cài đặt và các tạo phẩm đã sinh. Đóng gói và tải lên đã ký xảy ra nơi các tệp có thể truy cập; máy chủ MCP được lưu trữ không thể đọc thư mục cục bộ của tác nhân mã hóa.

Đối với ZIP hiện có, chuẩn bị tải lên:

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

Truyền cái này cho harness_execute. Kích thước phải mô tả ZIP thực tế; size_bytes, content_type, và md5 là tùy chọn và có thể null. Các trường chuẩn bị bổ sung được giữ lại để xác thực backend, như được phép bởi OpenAPI. Việc chuẩn bị trả về projectId, sourceId, và upload, bao gồm uploadUrl, method, headers, và expiresAt của mỗi tệp. Tải byte tệp trực tiếp bằng URL đã ký, phương thức và tiêu đề đó; giữ nguyên URL chính xác và không thêm thông tin xác thực Harness vào yêu cầu lưu trữ. Hành động chuẩn bị không đọc hoặc tải lên tệp cục bộ.

Sau khi tải lên thành công, triển khai một cách rõ ràng:

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

Đối với nhập JSON, sử dụng id được trả về thay thế. Triển khai cũng chấp nhận body: {"project_id": "<Vibe app id>"} hoặc params.app_id; trường dây API là snake_case project_id mặc dù chuẩn bị trả về camelCase projectId. project_id cấp cao nhất của công cụ chung là định danh phạm vi Harness và không bao giờ được sử dụng làm id ứng dụng Vibe. Nhập và chuẩn bị tạo ứng dụng/nguồn; cả hai đều không bắt đầu triển khai. Ghi không được tự động thử lại và triển khai sử dụng chính sách xác nhận rủi ro cao hiện có.

Đọc tiến trình với harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>"). Nó giữ lại URL ứng dụng, các giai đoạn thực thi, các bước con, lỗi, dòng nhật ký và chi tiết trình phân tích bản dựng. Hành động thực thi events chấp nhận resource_id hoặc params.app_id và tiêu thụ điểm cuối SSE như một lô hữu hạn: tối đa 20 sự kiện JSON hoặc năm giây sau khi kết nối, với giới hạn phản hồi 1 MiB. Các giới hạn này thuộc về điểm cuối Vibe. HARNESS_API_TIMEOUT_MS của kết nối cũng giới hạn tiêu thụ kết nối và luồng cùng nhau; hết hạn trả về lỗi hết thời gian. Một lô hoàn thành trả về events và stop_reason (end, event_limit, hoặc duration_limit) và đóng luồng. Cả lỗi kết nối ban đầu và luồng bị hỏng đều không được thử lại. Các sự kiện là khác biệt tạm thời không có con trỏ phát lại được ghi chú; sử dụng lấy vòng đời để có ảnh chụp nhanh có thẩm quyền. Cả hai lần đọc vòng đời đều có sẵn ở chế độ chỉ đọc.

Cờ tính năng

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
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

Tài nguyên FME (Split.io) — tài nguyên fme_* hỗ trợ phạm vi chế độ kép: các cuộc gọi kế thừa truyền workspace_id và truy cập API Split.io (api.split.io); các cuộc gọi mới hơn truyền org_id+project_id cùng nhau và truy cập các điểm cuối gốc Harness (HARNESS_API_KEY/HARNESS_BASE_URL tiêu chuẩn, cùng xác thực như mọi tài nguyên harness_* khác) thay thế. Truyền cả workspace_id và org_id/project_id trên cùng một cuộc gọi, hoặc trộn org_id với project_id một mình, là lỗi — chọn một chế độ cho mỗi cuộc gọi. Mọi thao tác bên dưới đều có sẵn ở chế độ kế thừa, không thay đổi, trừ khi tài nguyên được đánh dấu chỉ dành cho gốc Harness. Phạm vi bao phủ chế độ gốc Harness hiện đang hẹp hơn:

• fme_workspace — không có tương đương gốc Harness; chỉ dành cho hệ thống kế thừa (dùng để khám phá các giá trị workspace_id).

• fme_environment — chế độ kép list (workspace_id hoặc org_id+project_id). get/create/update/delete chỉ dành riêng cho Harness gốc (/fme/api/v4/environments) — MCP chưa bao giờ có hợp đồng workspace_id cho các thao tác này. Danh sách gốc dùng offset/limit tùy chọn (tối đa 100; harness_list size ánh xạ tới limit); {data, limit, offset, totalCount} của envelope được nâng cấp thành items/total. Tạo/cập nhật gốc dùng isProduction (production được chấp nhận như bí danh). Cập nhật gốc là JSON Merge Patch; name và isProduction không thể xóa. Tên tối đa 15 ký tự.

• fme_feature_flag — chế độ kép, cả hai nhánh đều được kết nối đầy đủ. Harness gốc (org_id+project_id): list/get/create/delete gọi tới /fme/api/v4/feature-flags (body cho create: name, trafficType, tùy chọn description/tags/owners, theo CreateFeatureFlagRequest); update gửi merge-patch tới /fme/api/v4/feature-flags/{name}; archive/unarchive gọi tới /fme/api/v4/feature-flags/{name}/archive|unarchive (chỉ comment tùy chọn — không có title, theo ArchiveUnarchiveRequest); kill/restore/reallocate gọi tới /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate với environment_id như tham số truy vấn (tùy chọn comment/title, theo FeatureFlagDefinitionActionRequest).

• fme_feature_flag_definition — get/create/update vẫn ở chế độ kép (workspace_id hoặc org_id+project_id). list/delete/kill/restore/reallocate chỉ dành riêng cho Harness gốc (org_id+project_id) — MCP chưa bao giờ có hợp đồng workspace_id cho các thao tác này. Danh sách gốc yêu cầu feature_flag_name và dùng offset/limit (mặc định 100, tối đa 100); không nhận environment_id. Xóa và thực thi yêu cầu environment_id. Kill/restore/reallocate là các hành động tương tự như trên fme_feature_flag. Body get/create/update khớp với hệ thống kế thừa (treatments, defaultTreatment, defaultRule, tùy chọn rules/baselineTreatment/trafficAllocation/comment), cộng thêm title tùy chọn trong chế độ Harness gốc. Cập nhật gốc là JSON Merge Patch.

• fme_rollout_status — list chế độ kép. Truyền org_id+project_id (ưu tiên) hoặc workspace_id đã không dùng nữa. Phân trang gốc dùng offset/limit (tối đa 100; harness_list size ánh xạ tới limit); kết quả được nâng cấp thành items/total. Mỗi mục có id, name và tùy chọn description.

• fme_rule_based_segment — (Không dùng nữa — xem fme_segment.) Chế độ Harness gốc bị từ chối trên mọi thao tác (list/get/create/delete) — hãy dùng fme_segment thay thế; tài nguyên này chỉ hỗ trợ hợp đồng workspace_id kế thừa.

• fme_rule_based_segment_definition — (Không dùng nữa — xem fme_segment_definition.) Chế độ Harness gốc bị từ chối trên mọi thao tác/hành động (list/update/enable/disable/change_request) — hãy dùng fme_segment_definition thay thế (không có tương đương enable/disable/change_request ở đó); tài nguyên này chỉ hỗ trợ hợp đồng workspace_id/environment_id kế thừa.

• fme_traffic_type — list chế độ kép. Truyền org_id+project_id (ưu tiên) hoặc workspace_id đã không dùng nữa. Phân trang gốc dùng offset/limit (tối đa 100; harness_list size ánh xạ tới limit); kết quả được nâng cấp thành items/total. Mỗi mục có id và name (không có displayAttributeId).

• fme_identity — create/update chưa được triển khai nếu org_id+project_id được truyền cùng nhau; nếu không, tiến hành như một lệnh gọi kế thừa thông thường.

• fme_standard_segment — không dùng nữa. workspace_id kế thừa vẫn gọi tới Split v2. Harness gốc bị từ chối — hãy dùng fme_segment.

• fme_segment_keys — list/update vẫn ở chế độ kế thừa (workspace_id / environment_id+segment_name). Harness gốc (org_id+project_id) bị từ chối — hãy dùng fme_segment_definition thực thi list_keys/add_keys/remove_keys.

• fme_segment — Chỉ dành cho gốc (org_id+project_id). CRUD. list/get/update/delete yêu cầu segment_type: STANDARD | LARGE | RULE_BASED. Body tạo: name, trafficType, segmentType; tùy chọn description, tags, owners.

• fme_segment_definition — Chỉ dành cho gốc. CRUD cộng thêm thực thi list_keys/add_keys/remove_keys. Cập nhật chỉ là mô tả. Xóa thất bại với hasDependents khi vẫn còn khóa.

• fme_metric — Chỉ dành riêng cho Harness gốc (không hỗ trợ workspace_id kế thừa). list/get/create/update/delete được kết nối tới /fme/api/v4/metrics (harness_list size của list ánh xạ tới limit). create yêu cầu spread mặc dù backend CreateMetricRequest vẫn giữ nó tùy chọn (mặc định PER) — một hợp đồng chặt chẽ hơn chỉ ở phía MCP, vì bỏ qua nó sẽ âm thầm thay đổi ngữ nghĩa của một chỉ số RATE. update là JSON Merge Patch; name/trafficType là bất biến và không được chấp nhận. delete là xóa cứng vĩnh viễn (không có lưu trữ/khôi phục) — được phân loại destructive.

• fme_event_type — Chỉ dành riêng cho Harness gốc (không hỗ trợ workspace_id kế thừa). Chỉ đọc: list/get được kết nối tới /fme/api/v4/event-types; id là tên sự kiện. Chỉ các loại sự kiện có sự kiện trong 30 ngày qua mới hiển thị; get trả về 404 cho một loại sự kiện nằm ngoài phạm vi loại lưu lượng của không gian làm việc yêu cầu, hoặc không hoạt động quá 30 ngày. Bộ lọc danh sách: name (chuỗi con), traffic_type (theo ID hoặc tên), offset/limit (harness_list size ánh xạ tới limit). Dùng tài nguyên này để khám phá ID loại sự kiện thực trước khi tham chiếu một ID trong baseEventTypes/filterEventType hoặc bộ lọc event_type_ids của fme_metric, thay vì đoán ID.

Trong chế độ người dùng đơn/tự lưu trữ, xác thực chế độ kế thừa dùng token Bearer từ HARNESS_FME_API_KEY, dự phòng sang HARNESS_API_KEY không phải placeholder. HARNESS_FME_API_KEY có thể là khóa quản trị Split kế thừa hoặc PAT/SAT Harness có quyền FME, nhưng bị từ chối trong chế độ multi-user để các triển khai dùng chung không thể ghi đè thông tin xác thực của người dùng từng phiên. Thông tin xác thực OAuth/định tuyến dịch vụ được lưu trữ cho API nền tảng Harness không xác thực các yêu cầu trực tiếp tới Split.io. fme_feature_flag hỗ trợ quản lý vòng đời đầy đủ ở chế độ kế thừa: tạo (yêu cầu traffic_type_id), danh sách, lấy, cập nhật siêu dữ liệu, xóa và các hành động thực thi kill/restore/reallocate/archive/unarchive. Dùng fme_traffic_type để khám phá ID loại lưu lượng, fme_identity để tạo/cập nhật thuộc tính danh tính và fme_standard_segment / fme_segment_keys để kiểm tra phân đoạn chuẩn và thêm khóa thành viên. fme_rule_based_segment cung cấp CRUD cho phân đoạn nhắm mục tiêu, trong khi fme_rule_based_segment_definition quản lý quy tắc phân đoạn theo môi trường với luồng bật/tắt và phê duyệt yêu cầu thay đổi.

GitOps

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Hành động thực thi
gitops_agent	x	x
gitops_argo_project	x
gitops_app_project_mapping	x		x	x	x	import
gitops_autocreate_log	x
gitops_application	x	x				sync
gitops_cluster	x	x
gitops_repository	x	x
gitops_applicationset	x	x
gitops_repo_credential	x	x
gitops_app_event	x
gitops_pod_log		x
gitops_managed_resource	x
gitops_resource_action	x
gitops_dashboard		x
gitops_app_resource_tree		x
gitops_cluster_link	x		x		x

Kỹ thuật hỗn loạn

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
chaos_experiment	x	x	x		x	run, stop
chaos_experiment_run		x
chaos_experiment_variable	x
chaos_component_variable		x
chaos_input_set	x	x	x	x	x
chaos_experiment_template	x	x			x	create_from_template, list_revisions, get_variables, get_yaml, compare_revisions
chaos_probe	x	x	x		x	enable, verify, get_manifest
chaos_probe_in_run	x
chaos_probe_template	x	x			x	get_variables
chaos_infrastructure	x
chaos_k8s_infrastructure	x	x	x			check_health
chaos_enabled_infrastructure	x
chaos_environment	x
chaos_hub	x	x	x	x	x
chaos_hub_fault	x
chaos_fault	x	x			x	get_variables, get_yaml
chaos_fault_template	x	x			x	list_revisions, get_variables, get_yaml, compare_revisions
chaos_fault_experiment_run	x
chaos_action	x	x	x		x	get_manifest
chaos_action_template	x	x			x	list_revisions, get_variables, compare_revisions
chaos_loadtest	x	x	x	x	x	run, stop
chaos_service	x	x	x	x	x	list_experiment_runs, list_load_tests
chaos_application_map	x	x
discovered_agent	x
discovered_namespace	x
discovered_service	x
discovered_network_map	x
chaos_guard_condition	x	x			x
chaos_guard_rule	x	x			x	enable
chaos_recommendation	x	x
chaos_risk	x	x
chaos_dr_test	x		x
scanned_risk	x	x				occurrences, summary_by_service
chaos_risk_rule	x	x
chaos_risk_scan	x	x	x	x	x	retry, abort, report, report_download, heatmap

Quản lý chi phí đám mây (CCM)

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
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

Thông tin chi tiết về kỹ thuật phần mềm (SEI)

Các tài nguyên SEI được hợp nhất để tối ưu hiệu quả token. Sử dụng tham số metric hoặc aspect cho DORA, chi tiết nhóm/cây tổ chức và thông tin chi tiết AI.

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
sei_metric	x
sei_productivity_metric		x
sei_dora_metric		x				Truyền metric: deployment_frequency, change_failure_rate, mttr, lead_time, hoặc *_drilldown
sei_team	x	x
sei_team_detail	x					Truyền aspect: integrations, developers, integration_filters
sei_org_tree	x	x
sei_org_tree_detail	x	x				Truyền aspect: efficiency_profile, productivity_profile, business_alignment_profile, integrations, teams
sei_business_alignment	x	x				Truyền aspect: feature_metrics, feature_summary, drilldown cho lấy
sei_ai_usage	x	x				Truyền aspect: metrics, breakdown, summary, top_languages
sei_ai_adoption	x	x				Truyền aspect: metrics, breakdown, summary
sei_ai_impact		x				Truyền aspect: pr_velocity, rework
sei_ai_raw_metric	x

Đảm bảo chuỗi cung ứng phần mềm (SCS)

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
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

Kho Bằng Chứng

Kho Bằng Chứng lưu trữ các xác nhận in-toto (bằng chứng SDLC). Danh sách hỗ trợ phạm vi tài khoản/tổ chức/dự án qua resource_scope. Bộ lọc văn bản tự do số ít (đường dẫn, artifact riêng lẻ, gitoid) sử dụng search_term; một ràng buộc Tên bổ sung sử dụng filters.subject_name; hàm băm nội dung chủ thể sử dụng filters.subject_digest. Lấy tra cứu theo gitoid_sha256 và yêu cầu org_id/project_id (từ hàng danh sách). Tải xuống (hành động harness_execute download) trả về download_url có giới hạn thời gian — luôn hiển thị liên kết đó cho người dùng. Yêu cầu cờ tính năng SCS_EVIDENCE_VAULT.

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
attestation	x	x				download

Điều phối Kiểm thử Bảo mật (STO)

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
security_issue	x
security_issue_filter	x
security_exemption	x		x			approve, reject
remediation_diff	x

Việc tạo security_exemption là một thao tác high_write. Máy chủ suy ra requester_id từ PAT đã xác thực, đặt exemptFutureOccurrences=true, và mặc định duration_days thành 30 khi không được cung cấp. Để liệt kê các miễn trừ, hãy truyền kích thước trang nhỏ rõ ràng (ví dụ filters: { "status": "Pending", "size": 5 }) và làm theo _nextPageHint được trả về trong mỗi phản hồi.

Quy trình thực thi miễn trừ bảo mật:

• Sử dụng harness_list với resource_type="security_exemption" và một status rõ ràng như Pending, Approved, Rejected, Expired, hoặc Canceled.
• Sử dụng harness_execute với action="approve" và một body.scope bắt buộc: CURRENT, ACCOUNT, ORG, hoặc PROJECT. CURRENT phê duyệt ở phạm vi hiện có của miễn trừ; các phạm vi khác sử dụng điểm cuối thăng cấp STO nội bộ. Máy chủ tự động điền body.approver_id từ người dùng đã xác thực khi bỏ trống; body.comment là tùy chọn.
• Sử dụng action="reject" để từ chối một miễn trừ. body.approver_id cũng được tự động điền khi bỏ trống.
• Không có hành động thực thi promote riêng biệt. Sử dụng action="approve" với một body.scope không phải CURRENT khi kết quả yêu cầu là phê duyệt ở phạm vi tài khoản, tổ chức, hoặc dự án.

Kiểm soát Truy cập

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
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

Quản trị

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
policy	x	x	x	x	x
policy_set	x	x	x	x	x
policy_evaluation	x	x

Đóng băng Triển khai

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
freeze_window	x	x	x	x	x	toggle_status
global_freeze		x				manage

Ghi đè Dịch vụ

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
service_override	x	x	x	x	x

Cài đặt

Loại tài nguyên	Danh sách	Lấy	Tạo	Cập nhật	Xóa	Thực thi hành động
setting	x

Lời nhắc MCP

DevOps

Prompt	Mô tả	Tham số
build-deploy-app	Quy trình CI/CD đầu cuối: quét kho git, tạo pipeline CI (build & push Docker image), khám phá hoặc tạo K8s manifests, tạo pipeline CD, và triển khai — với tự động thử lại khi CI thất bại (tối đa 5 lần) và CD thất bại (tối đa 3 lần với sự cho phép của người dùng). Khi đã cạn số lần thử lại, cung cấp các liên kết sâu đến giao diện Harness cho tất cả tài nguyên đã tạo để điều tra thủ công.	repoUrl (bắt buộc), imageName (bắt buộc), projectId (tùy chọn), namespace (tùy chọn)
debug-pipeline-failure	Phân tích một lần thực thi thất bại: chấp nhận một execution ID, pipeline ID, hoặc Harness URL. Lấy thông tin phân tích stage/step, chi tiết lỗi, thông tin delegate, và log của step thất bại qua harness_diagnose, sau đó cung cấp phân tích nguyên nhân gốc và các đề xuất khắc phục. Tự động theo dõi các lỗi pipeline liên chuỗi.	executionId (tùy chọn), projectId (tùy chọn)
pipeline_summarizer	Lấy và tóm tắt TẤT CẢ log của các step từ một lần thực thi pipeline. Sử dụng harness_diagnose với include_logs: true, include_all_step_logs: true để lấy log của từng step, sau đó trình bày một bảng với Tên Step, Trạng thái, Thời lượng, và Điều gì đã xảy ra (tóm tắt dựa trên log). KHÔNG bỏ qua bất kỳ step nào.	executionId (tùy chọn), projectId (tùy chọn)
create-pipeline	Tạo một pipeline YAML mới từ các yêu cầu ngôn ngữ tự nhiên, xem xét các tài nguyên hiện có để có ngữ cảnh	description (bắt buộc), projectId (tùy chọn)
create-agent	Xây dựng tương tác một Harness AI agent — kiểm tra các agent hiện có (phát hiện định dạng spec agent.uses hiện tại so với agent.step.group.steps cũ khi cập nhật), thu thập yêu cầu, tạo spec agent ở định dạng phù hợp, xác nhận với người dùng, sau đó tạo hoặc cập nhật qua harness_create/harness_update	agent_name (bắt buộc), task_description (bắt buộc), org_id (tùy chọn), project_id (tùy chọn)
onboard-service	Hướng dẫn từng bước onboarding một dịch vụ mới với môi trường và một pipeline triển khai	serviceName (bắt buộc), projectId (tùy chọn)
dora-metrics-review	Xem xét các chỉ số DORA (tần suất triển khai, tỷ lệ thất bại thay đổi, MTTR, thời gian dẫn dắt) với phân loại Elite/High/Medium/Low và các khuyến nghị cải thiện	teamRefId (tùy chọn), dateStart (tùy chọn), dateEnd (tùy chọn)
setup-gitops-application	Hướng dẫn onboarding một ứng dụng GitOps — xác minh agent, cluster, repo, và tạo ứng dụng	agentId (bắt buộc), projectId (tùy chọn)
chaos-resilience-test	Thiết kế một thử nghiệm chaos để kiểm tra khả năng phục hồi của dịch vụ với việc tiêm lỗi, probe, và kết quả mong đợi	serviceName (bắt buộc), projectId (tùy chọn)
feature-flag-rollout	Lập kế hoạch và thực hiện triển khai dần dần một feature flag qua các môi trường với các cổng an toàn	flagIdentifier (bắt buộc), projectId (tùy chọn)
migrate-pipeline-to-template	Phân tích một pipeline hiện có và trích xuất các template stage/step có thể tái sử dụng từ đó	pipelineId (bắt buộc), projectId (tùy chọn)
delegate-health-check	Kiểm tra kết nối delegate, tình trạng sức khỏe, trạng thái token, và khắc phục các vấn đề hạ tầng	projectId (tùy chọn)
developer-portal-scorecard	Xem xét các scorecard IDP cho các dịch vụ và xác định khoảng trống để cải thiện trải nghiệm nhà phát triển	projectId (tùy chọn)
pending-approvals	Tìm các lần thực thi pipeline đang chờ phê duyệt, hiển thị chi tiết, và đề nghị phê duyệt hoặc từ chối	projectId (tùy chọn), orgId (tùy chọn), pipelineId (tùy chọn)

FinOps

Prompt	Mô tả	Tham số
optimize-costs	Phân tích dữ liệu chi phí đám mây, đưa ra các khuyến nghị và bất thường, ưu tiên theo khả năng tiết kiệm tiềm năng	projectId (tùy chọn)
cloud-cost-breakdown	Đi sâu vào chi phí đám mây theo dịch vụ, môi trường, hoặc cluster với phân tích xu hướng và phát hiện bất thường	perspectiveId (tùy chọn), projectId (tùy chọn)
commitment-utilization-review	Phân tích việc sử dụng reserved instance và savings plan để tìm lãng phí và tối ưu hóa cam kết	projectId (tùy chọn)
cost-anomaly-investigation	Điều tra các bất thường chi phí — xác định nguyên nhân gốc, tài nguyên bị ảnh hưởng, và khắc phục	projectId (tùy chọn)
rightsizing-recommendations	Xem xét và ưu tiên các khuyến nghị rightsizing, tùy chọn tạo ticket Jira hoặc ServiceNow	projectId (tùy chọn), minSavings (tùy chọn)

DevSecOps

Prompt	Mô tả	Tham số
security-review	Xem xét các vấn đề bảo mật trên các tài nguyên Harness và đề xuất khắc phục theo mức độ nghiêm trọng	projectId (tùy chọn), severity (tùy chọn, mặc định: critical,high)
vulnerability-triage	Phân loại các lỗ hổng bảo mật trên các pipeline và artifact, ưu tiên theo mức độ nghiêm trọng và khả năng khai thác	projectId (tùy chọn), severity (tùy chọn)
sbom-compliance-check	Kiểm toán SBOM và tình trạng tuân thủ cho các artifact — rủi ro giấy phép, vi phạm chính sách, lỗ hổng thành phần	artifactId (tùy chọn), projectId (tùy chọn)
supply-chain-audit	Kiểm toán bảo mật chuỗi cung ứng phần mềm đầu cuối — nguồn gốc, chuỗi lưu giữ, tuân thủ chính sách	projectId (tùy chọn)
security-exemption-review	Xem xét các miễn trừ bảo mật đang chờ xử lý và đưa ra quyết định phê duyệt hoặc từ chối hàng loạt	projectId (tùy chọn)
bulk-exemption-create	Tạo các miễn trừ bảo mật có lý do cho nhiều vấn đề STO với hướng dẫn phạm vi và thời hạn rõ ràng	projectId (bắt buộc), exemption_type (bắt buộc), reason (bắt buộc), bộ lọc vấn đề (tùy chọn)
access-control-audit	Kiểm toán quyền người dùng, tài khoản có quá nhiều quyền, và phân công vai trò để thực thi nguyên tắc đặc quyền tối thiểu	projectId (tùy chọn), orgId (tùy chọn)

Harness Code

Prompt	Mô tả	Tham số
code-review	Xem xét một pull request — phân tích diff, commit, kiểm tra và bình luận để cung cấp phản hồi có cấu trúc về lỗi, bảo mật, hiệu suất và phong cách	repoId (bắt buộc), prNumber (bắt buộc), projectId (tùy chọn)
pr-summary	Tự động tạo tiêu đề và mô tả PR từ lịch sử commit và diff của một nhánh	repoId (bắt buộc), sourceBranch (bắt buộc), targetBranch (tùy chọn, mặc định: main), projectId (tùy chọn)
branch-cleanup	Phân tích các nhánh trong một kho lưu trữ và đề xuất các nhánh lỗi thời hoặc đã hợp nhất để xóa	repoId (bắt buộc), projectId (tùy chọn)

Tài nguyên MCP

Resource URI	Mô tả	Loại MIME
pipeline:///{pipelineId}	Định nghĩa YAML pipeline	application/x-yaml
pipeline:///{orgId}/{projectId}/{pipelineId}	YAML pipeline (có phạm vi rõ ràng)	application/x-yaml
executions:///recent	Tóm tắt 10 lần thực thi pipeline gần nhất	application/json
schema:///pipeline	Lược đồ JSON pipeline Harness	application/schema+json
schema:///template	Lược đồ JSON mẫu Harness	application/schema+json
schema:///trigger	Lược đồ JSON trigger Harness	application/schema+json
schema:///pipeline_v1 (Alpha)	Lược đồ JSON pipeline Harness V1 (định dạng stages/steps đơn giản hóa)	application/schema+json
schema:///agent-pipeline	Lược đồ JSON pipeline agent AI Harness	application/schema+json
agent-docs:///legacy-format	Tham chiếu định dạng spec agent kế thừa (agent.step.group.steps / PLUGIN_TASK), được đọc bởi prompt create-agent khi cập nhật một agent định dạng kế thừa hiện có	text/markdown

Lọc bộ công cụ

Theo mặc định, 41 trong số 45 bộ công cụ được bật. Bốn bộ công cụ là tùy chọn và bị loại khỏi các mặc định:

• ansible — Harness Ansible (inventories, playbooks, hosts, activity). Tùy chọn vì nó có phạm vi dự án và thêm các khái niệm mà nhiều người dùng không cần.
• autonomous_work — Development Harness (công việc tự động). Tùy chọn; xem mô tả bộ công cụ để biết phạm vi.
• observability-evaluations — Các quy tắc đánh giá telemetry sản xuất theo lịch trình. Tùy chọn vì nó phụ thuộc vào control plane chấm điểm đã triển khai.
• registries-v3 — Harness Artifact Registry v3 (packages, versions, files, metadata, scans, firewall exceptions). Tùy chọn cho đến khi các bản ghi v3 được triển khai, để các agent không phải phân biệt giữa v1 registries/artifacts và v3 packages/versions.

Thêm bộ công cụ với tiền tố +

Sử dụng tiền tố + để bao gồm rõ ràng các bộ công cụ tùy chọn cùng với tất cả các mặc định:

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

Loại bỏ các bộ công cụ mặc định

Sử dụng tiền tố - để loại trừ các bộ công cụ bạn không cần:

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

Kết hợp + và -

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

Danh sách cho phép rõ ràng

Một danh sách phân tách bằng dấu phẩy rõ ràng (không có tiền tố) thay thế hoàn toàn các mặc định. Chỉ các bộ công cụ được liệt kê mới được bật:

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

Tên bộ công cụ khả dụng:

Bộ công cụ	Các loại tài nguyên
platform	organization, project
pipelines	pipeline, pipeline_v1, pipeline_dynamic_execution, execution, execution_inputs, trigger, pipeline_summary, input_set, approval_instance
agents	agent, agent_run
services	service
environments	environment
connectors	connector, connector_catalogue
infrastructure	infrastructure
secrets	secret
logs	execution_log
audit	audit_event
delegates	delegate, delegate_token
repositories	repository, branch, commit, file_content, tag, repo_rule, space_rule
registries	registry, artifact, artifact_version, artifact_file
file_store	file_store
templates	template
dashboards	dashboard, dashboard_data
idp	idp_entity, scorecard, scorecard_check, scorecard_stats, scorecard_check_stats, idp_score, idp_workflow, idp_tech_doc
pull-requests	pull_request, pr_reviewer, pr_comment, pr_check, pr_activity
feature-flags	fme_workspace, fme_environment, fme_feature_flag, fme_feature_flag_definition, fme_rollout_status, fme_rule_based_segment, fme_rule_based_segment_definition, fme_traffic_type, fme_identity, fme_standard_segment, fme_segment_keys, fme_segment, fme_segment_definition, fme_metric, fme_event_type
gitops	gitops_agent, gitops_argo_project, gitops_app_project_mapping, gitops_autocreate_log, gitops_application, gitops_cluster, gitops_repository, gitops_applicationset, gitops_repo_credential, gitops_app_event, gitops_pod_log, gitops_managed_resource, gitops_resource_action, gitops_dashboard, gitops_app_resource_tree, gitops_cluster_link
chaos	chaos_experiment, chaos_experiment_run, chaos_experiment_variable, chaos_component_variable, chaos_input_set, chaos_experiment_template, chaos_probe, chaos_probe_in_run, chaos_probe_template, chaos_infrastructure, chaos_k8s_infrastructure, chaos_enabled_infrastructure, chaos_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan
ccm	cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment
sei	sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric
scs	scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom
evidence-vault	attestation
sto	security_issue, security_issue_filter, security_exemption, remediation_diff
dbops	database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline
autonomous_work (tùy chọn)	work_item, work_item_resume, work_item_approve, work_timeline, work_budget, work_phase, work_phase_artifact, work_artifact, budget, budget_grant, budget_usage, work_class, work_trigger, capability, risk_evaluator, team, member, member_template, software_component, content_source_connector
access_control	user, user_group, service_account, role, role_assignment, resource_group, permission
governance	policy, policy_set, policy_evaluation
freeze	freeze_window, global_freeze
overrides	service_override
settings	setting
knowledge-graph	kg_queryable_type_summary, kg_grammar, hql_query
semantic-layer	kg_type, kg_related_type
ai-evals	eval_dataset, eval_dataset_item, evaluation, eval_run, eval_run_item, eval_run_by_eval, eval_metric, eval_metric_set, eval_metric_set_entry, eval_suite, eval_suite_evaluation, eval_suite_run, eval_target, eval_annotation, eval_analytics, eval_git_settings, eval_registry_item, eval_git_registration, online_eval
observability-evaluations (tùy chọn)	observability_evaluation_rule
iacm	iacm_workspace, iacm_variable_set, iacm_resource, iacm_module, iacm_provider, iacm_workspace_costs, iacm_activity_resource_change
ansible (tùy chọn)	ansible_inventory, ansible_playbook, ansible_host, ansible_host_activity, ansible_activity
registries-v3 (tùy chọn)	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

Kiến trúc

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

Cách hoạt động

1. Công cụ là các động từ chung: harness_list, harness_get, v.v. Chúng chấp nhận tham số resource_type để định tuyến đến điểm cuối API chính xác.
2. Registry ánh xạ mỗi resource_type đến một ResourceDefinition — một cấu trúc dữ liệu khai báo xác định phương thức HTTP, đường dẫn URL, ánh xạ tham số đường dẫn/truy vấn và logic trích xuất phản hồi.
3. Dispatch phân giải định nghĩa tài nguyên, xây dựng yêu cầu HTTP (thay thế đường dẫn, tham số truy vấn, tiêm tài khoản/tổ chức/dự án nhận biết resource_scope), gọi API Harness thông qua HarnessClient và trích xuất dữ liệu phản hồi liên quan.
4. Lọc bộ công cụ (HARNESS_TOOLSETS) kiểm soát định nghĩa tài nguyên nào được tải vào registry khi khởi động.
5. Đầu ra có cấu trúc được khai báo với MCP outputSchema; harness_list ép các mảng và trình bao bọc danh sách phổ biến thành structuredContent có hình dạng đối tượng cho các máy khách nghiêm ngặt.
6. Liên kết sâu được tự động thêm vào phản hồi, cung cấp URL giao diện Harness trực tiếp cho mọi tài nguyên.
7. Chế độ gọn nhẹ loại bỏ siêu dữ liệu dài dòng khỏi kết quả danh sách, chỉ giữ các trường có thể hành động (danh tính, trạng thái, loại, dấu thời gian, liên kết sâu) để giảm thiểu việc sử dụng token.

Thêm loại tài nguyên mới

Tạo một tệp mới trong src/registry/toolsets/ hoặc thêm tài nguyên vào bộ công cụ hiện có:

// 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",
        },
      },
    },
  ],
};

Sau đó nhập nó trong src/registry/index.ts và thêm nó vào mảng ALL_TOOLSETS. Không cần thay đổi bất kỳ tệp công cụ nào.

Phát triển

# 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

Cấu trúc dự án

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

Khơi gợi

Các công cụ ghi (harness_create, harness_update, harness_delete, harness_execute) sử dụng khơi gợi MCP để nhắc người dùng xác nhận khi rủi ro của hành động yêu cầu — chỉ các thao tác medium_write, high_write và destructive. Các thao tác tạo / cập nhật / đọc có rủi ro thấp (ví dụ: pipeline.create, pipeline.update, hql_query.run) tiến hành âm thầm mà không có lời nhắc. Khi lời nhắc được hiển thị, người dùng sẽ thấy những gì sắp xảy ra và chấp nhận hoặc từ chối, mang lại sự phê duyệt thực sự của con người trong vòng lặp cho các thao tác thực sự thay đổi hoặc chạy mọi thứ.

Cách hoạt động:

1. LLM gọi một công cụ ghi với rủi ro medium_write+ (ví dụ: harness_delete, harness_execute pipeline.run). Các thao tác tạo / cập nhật / đọc có rủi ro thấp không hiển thị lời nhắc.
2. Máy chủ gửi yêu cầu khơi gợi đến máy khách với bản tóm tắt thao tác và hộp kiểm confirm (được chọn theo mặc định).
3. Người dùng xem chi tiết và nhấp vào Chấp nhận (với confirm được chọn) hoặc Từ chối / Hủy.
4. Nếu được chấp nhận với confirm: true, thao tác sẽ tiến hành. Nếu được chấp nhận với confirm không được chọn, bị từ chối hoặc bị hủy, thao tác sẽ bị chặn và LLM được thông báo (một sự từ chối rõ ràng là có thẩm quyền và không bị bỏ qua bởi confirm: true trên lệnh gọi công cụ).

Hỗ trợ máy khách:

Máy khách	Hỗ trợ khơi gợi
Cursor	Có
VS Code (Copilot)	Có
Claude Desktop	Chưa có
Devin Desktop	Chưa có
MCP Inspector	Có

Hành vi khơi gợi thay đổi theo mức độ rủi ro của thao tác khi thiếu hỗ trợ máy khách:

Mức rủi ro	Máy khách hỗ trợ khơi gợi	confirm: true được truyền	Hành vi
read, low_write	bất kỳ	bất kỳ	Tiến hành âm thầm — không hiển thị lời nhắc (confirm không có hiệu lực ở mức rủi ro này)
medium_write, high_write, destructive	Có	bất kỳ	Nhắc người dùng. Chỉ tiến hành nếu người dùng chấp nhận với confirm: true (mặc định của lược đồ). Một sự từ chối rõ ràng, hủy hoặc chấp nhận với confirm: false (người dùng bỏ chọn hộp) là có thẩm quyền và không bị bỏ qua bởi confirm: true trên lệnh gọi công cụ. Một sự chấp nhận thiếu trường confirm được coi là máy khách không hiển thị được lời nhắc có thể sử dụng — có thể khôi phục bằng cách thử lại với confirm: true
medium_write, high_write, destructive	Không	Không	CHẶN (trả về lỗi với gợi ý thử lại với confirm: true)
medium_write, high_write, destructive	Không	Có	Tiến hành (chọn tham gia rõ ràng cho tự động hóa không tương tác)
bất kỳ (ở hoặc dưới HARNESS_AUTO_APPROVE_RISK)	bất kỳ	bất kỳ	Tự động phê duyệt mà không nhắc

Nếu elicitInput thất bại trong thời gian chạy (lỗi truyền tải, phương thức không được hỗ trợ) cho thao tác medium_write+, lệnh gọi sẽ bị chặn trừ khi người gọi truyền confirm: true. confirm: true được tôn trọng như một phương án dự phòng khi máy khách không thể hiển thị lời nhắc hoặc trả về một sự chấp nhận suy biến ({action: "accept"} không có trường xác nhận), nhưng nó không ghi đè sự từ chối/hủy rõ ràng từ máy khách đã hoàn thành bắt tay khơi gợi.

Chế độ tự động

Chế độ tự động có nghĩa là máy chủ tiến hành tất cả các thao tác — bao gồm cả ghi và hành động phá hủy — mà không nhắc xác nhận. Kích hoạt bằng cách đặt:

HARNESS_AUTO_APPROVE_RISK=all

Đây là giới hạn cấp triển khai: khi đã được đặt, các phiên riêng lẻ không thể vượt quá giới hạn đó (mặc dù chúng có thể chọn ngưỡng nghiêm ngặt hơn cho mỗi phiên thông qua tiêu đề x-harness-auto-approve-risk).

Hoặc trong cấu hình máy khách MCP của bạn:

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

Tự động một phần: Bạn cũng có thể tự động phê duyệt chỉ đến một mức rủi ro cụ thể trong khi vẫn nhắc cho các thao tác có rủi ro cao hơn:

# 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

Giá trị	Những gì được tự động phê duyệt
none (mặc định)	Không có gì — không có ngưỡng tự động phê duyệt
low_write	Đọc + ghi rủi ro thấp
medium_write	Đọc + ghi rủi ro thấp + trung bình
high_write	Đọc + ghi rủi ro thấp + trung bình + cao
all	Mọi thứ, bao gồm cả thao tác phá hủy

Cảnh báo chế độ tự động: HARNESS_AUTO_APPROVE_RISK=all bỏ qua xác nhận cho tất cả các thao tác bao gồm cả harness_delete. Sử dụng thận trọng và cân nhắc kết hợp với HARNESS_TOOLSETS để hạn chế loại tài nguyên nào có sẵn.

Ghi chú di chuyển: HARNESS_SKIP_ELICITATION=true vẫn được hỗ trợ và ánh xạ đến HARNESS_AUTO_APPROVE_RISK=all. Một cảnh báo không dùng nữa được ghi vào stderr. Nếu cả hai được đặt, HARNESS_AUTO_APPROVE_RISK được ưu tiên.

An toàn

• Bí mật không bao giờ bị lộ. Loại tài nguyên secret chỉ trả về siêu dữ liệu (tên, loại, phạm vi) — giá trị bí mật không bao giờ được bao gồm trong bất kỳ phản hồi nào.
• Các thao tác yêu cầu xác nhận sử dụng khơi gợi khi có sẵn. Khi một hành động ghi hoặc thực thi có rủi ro medium_write, high_write hoặc destructive, harness_create, harness_update, harness_delete và harness_execute cố gắng khơi gợi MCP trước khi tiến hành (xem Khơi gợi). Các hành động rủi ro thấp (read, low_write — ví dụ: pipeline.create, pipeline.update, hql_query.run) tiến hành âm thầm mà không có lời nhắc.
• Rủi ro trung bình trở lên đóng khi thất bại. Nếu không thể lấy được xác nhận cho các thao tác medium_write, high_write hoặc destructive, chúng sẽ bị chặn thay vì thực thi một cách mù quáng. Ghi đè bằng HARNESS_AUTO_APPROVE_RISK cho các quy trình làm việc tự động.
• CORS giới hạn cùng nguồn gốc. Truyền tải HTTP chỉ cho phép các yêu cầu cùng nguồn gốc, ngăn chặn các cuộc tấn công CSRF từ các trang web độc hại nhắm vào máy chủ MCP trên localhost.
• Giới hạn tốc độ HTTP. Truyền tải HTTP thực thi 60 yêu cầu mỗi phút cho mỗi IP để ngăn chặn tràn ngập yêu cầu.
• Giới hạn tốc độ API. Máy khách API Harness thực thi giới hạn 10 yêu cầu/giây để tránh đạt giới hạn tốc độ thượng nguồn.
• Giới hạn phân trang được thực thi. Truy vấn danh sách được giới hạn ở tổng cộng 10.000 mục và 100 mỗi trang để ngăn chặn cạn kiệt bộ nhớ.
• Thử lại với backoff. Các lỗi tạm thời (HTTP 429, 5xx) được thử lại với backoff theo cấp số nhân và jitter.
• Ràng buộc localhost. Truyền tải HTTP liên kết với 127.0.0.1 theo mặc định — không thể truy cập từ mạng.
• Không ghi nhật ký stdout. Tất cả nhật ký đi đến stderr để tránh làm hỏng truyền tải JSON-RPC stdio.

Kỹ năng bổ sung

Máy chủ MCP Harness kết hợp tốt với Kỹ năng Harness — một bộ sưu tập các kỹ năng Claude Code làm sẵn (lệnh gạch chéo) được thiết kế cho các quy trình làm việc Harness phổ biến. Cài đặt chúng cùng với máy chủ MCP này để có được tự động hóa cấp cao như /deploy, /rollback, /triage và hơn thế nữa mà không cần viết lời nhắc tùy chỉnh.

Xử lý sự cố & Cạm bẫy phổ biến

Triệu chứng	Nguyên nhân có khả năng	Cách xử lý
HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...	Khóa API không ở định dạng theo phạm vi tài khoản được hỗ trợ (pat.<accountId>... hoặc sat.<accountId>...) nên không thể suy ra ID tài khoản	Đặt HARNESS_ACCOUNT_ID một cách tường minh
Unknown transport: "..." khi khởi động	Đối số CLI transport không được hỗ trợ	Chỉ sử dụng stdio hoặc http
Invalid HARNESS_TOOLSETS: ... khi khởi động	Một hoặc nhiều tên toolset không được nhận diện	Chỉ sử dụng các tên từ Lọc Toolset (khớp chính xác)
HTTP mcp-session-id header is required...	Một yêu cầu phiên được gửi mà không có header phiên	Gửi initialize trước, sau đó bao gồm mcp-session-id trên POST/GET/DELETE /mcp
HTTP Session not found...	Phiên đã hết hạn sau MCP_SESSION_TTL_MS mili giây không hoạt động hoặc đã bị đóng	Chạy lại initialize để tạo phiên mới, sau đó thử lại với header mới
HTTP 405 Method Not Allowed trên /mcp	Phương thức không được hỗ trợ cho endpoint MCP	Chỉ sử dụng POST, GET, DELETE hoặc OPTIONS
HTTP Invalid request	Nội dung JSON không hợp lệ hoặc nội dung yêu cầu vượt quá HARNESS_MAX_BODY_SIZE_MB	Xác thực kích thước/hình dạng payload JSON; tăng HARNESS_MAX_BODY_SIZE_MB nếu cần
Unknown resource_type "..." từ các công cụ	Loại tài nguyên bị viết sai chính tả hoặc bị lọc qua HARNESS_TOOLSETS	Gọi harness_describe (với search_term tùy chọn) để khám phá các loại hợp lệ
Missing required field "... for path parameter ..."	Một lệnh gọi theo phạm vi dự án/tổ chức thiếu định danh	Đặt HARNESS_ORG/HARNESS_PROJECT hoặc truyền org_id/project_id cho mỗi lệnh gọi công cụ
resource_scope "org" requires org_id... hoặc resource_scope "project" requires project_id...	Một tài nguyên đa phạm vi bị ép vào phạm vi tổ chức/dự án mà không có đủ định danh	Truyền org_id/project_id còn thiếu, cấu hình HARNESS_ORG/HARNESS_PROJECT hoặc sử dụng resource_scope: "account" khi được hỗ trợ
Read-only mode is enabled ... operations are not allowed	HARNESS_READ_ONLY=true chặn các thao tác tạo/cập nhật/xóa/thực thi	Đặt HARNESS_READ_ONLY=false nếu các thao tác ghi được dự định
Chạy pipeline thất bại trước khi kiểm tra với các đầu vào bắt buộc chưa được giải quyết	inputs được cung cấp không bao phủ các placeholder thời gian chạy bắt buộc	Tìm nạp runtime_input_template, cung cấp các khóa đơn giản còn thiếu hoặc sử dụng input_set_ids cho các đầu vào có cấu trúc
Ký hiệu rút gọn CI pipeline (branch, tag, pr_number, commit_sha) không được áp dụng	inputs.build đã được cung cấp, nên việc mở rộng ký hiệu rút gọn đã bị bỏ qua có chủ đích	Xóa inputs.build để sử dụng mở rộng ký hiệu rút gọn hoặc giữ cấu trúc build tường minh đầy đủ
Chạy pipeline tải sai bản sửa đổi YAML	Định nghĩa pipeline được lưu trong Git và lần chạy không chỉ định nhánh pipeline mong muốn	Truyền params.pipeline_branch trên hành động run; điều này ánh xạ tới branch của Harness
wait: true trả về _wait.error	Trình kích hoạt pipeline thành công, nhưng việc thăm dò phía máy chủ thất bại	Kiểm tra lại execution_id bằng harness_get(resource_type="execution", ...) trước khi quyết định chạy lại
wait: true trả về execution_timed_out: true	Quá trình thực thi không đạt trạng thái cuối trước wait_timeout_seconds	Sử dụng execution_id được trả về để kiểm tra lại trạng thái; chờ trạng thái cuối trước khi chạy harness_diagnose
Nhật ký thực thi trống hoặc tải blob trả về 403	URL blob nhật ký do Harness lưu trữ yêu cầu đường dẫn máy khách/xác thực Harness được cấu hình, đặc biệt cho các máy chủ nội bộ hoặc tự quản lý	Giữ HARNESS_BASE_URL trỏ tới máy chủ Harness mục tiêu và sử dụng harness_get(resource_type="execution_log", ...) hoặc harness_diagnose(..., include_logs=true) thay vì bỏ qua máy khách MCP
Operation declined by user / Operation cancelled by user	Người dùng từ chối hoặc hủy hộp thoại xác nhận elicitation — có thẩm quyền	Xác minh chi tiết thao tác với người dùng; confirm: true không bỏ qua việc từ chối tường minh. Người dùng phải chấp nhận lời nhắc
Operation blocked: the client could not surface a usable confirmation prompt	Máy khách thiếu hỗ trợ elicitation, elicitInput thất bại hoặc trả về chấp nhận suy biến	Thử lại với confirm: true cho tự động hóa không tương tác hoặc sử dụng máy khách hỗ trợ elicitation
body.template_yaml (or body.yaml) is required cho tạo/cập nhật mẫu	API mẫu mong đợi payload YAML đầy đủ	Cung cấp chuỗi template_yaml đầy đủ trong body; để xóa, truyền version_label để xóa một phiên bản (bỏ qua để xóa tất cả phiên bản)
HARNESS_BASE_URL must use HTTPS khi khởi động	HARNESS_BASE_URL được đặt thành URL HTTP	Sử dụng HTTPS hoặc đặt HARNESS_ALLOW_HTTP=true cho phát triển cục bộ

Giấy phép

MIT