Harness

chính thức

Truy cập và tương tác với dữ liệu nền tảng Harness, bao gồm pipeline, kho lưu trữ, nhật ký và registry artifact.

Bạn có thể làm gì với Harness MCP?

Liệt kê bất kỳ tài nguyên Harness nào — Yêu cầu pipeline, dịch vụ, cờ tính năng hoặc dữ liệu chi phí chỉ với một lệnh gọi harness_list thay vì hàng trăm công cụ cụ thể cho từng endpoint.
Lấy chi tiết tài nguyên — Kéo cấu hình đầy đủ của pipeline, môi trường hoặc dự án bằng harness_get trên 224 loại tài nguyên.
Khám phá tổ chức và dự án một cách linh hoạt — Yêu cầu về các lỗi "trên tất cả các dự án" và tác nhân sẽ điều hướng hệ thống phân cấp tài khoản qua harness_list(resource_type="project").
Tạo và quản lý tài nguyên — Cung cấp hoặc cập nhật pipeline, dịch vụ, môi trường và cờ tính năng thông qua các công cụ harness_create (và các công cụ liên quan) được hợp nhất.
Chạy các lời nhắc quy trình làm việc dựng sẵn — Kích hoạt 34 mẫu tích hợp để xây dựng và triển khai ứng dụng, gỡ lỗi pipeline lỗi, xem xét chỉ số DORA và phân loại lỗ hổng bảo mật.
Kiểm soát rủi ro ghi tự động — Đặt HARNESS_AUTO_APPROVE_RISK để các thao tác rủi ro thấp tự động phê duyệt trong khi các thay đổi rủi ro hơn yêu cầu xác nhận.

Tài liệu

Máy chủ MCP Harness 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à 224 loại tài nguyên.

Vì 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 endpoint 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 schema, và mỗi endpoint mới đồng nghĩa với việc viết mã mới.

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

11 công cụ, 224 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, feature flag, dữ liệu chi phí, và nhiều hơn nữa. LLM chọn từ 11 công cụ thay vì hàng trăm công cụ.
Bao phủ toàn bộ nền tảng. 38 bộ công cụ mặc định bao gồm CI/CD, GitOps, Feature Flags, 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 trị, Ghi đè Dịch vụ, Đồ thị Tri thức, và nhiều hơn nữa. Hỗ trợ Ansible tùy chọn có sẵn khi bạn cần dữ liệu kiểm kê và playbook.
Quy trình làm việc đa dự án sẵn 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 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.
34 mẫu prompt. Các prompt được xây dựng sẵn cho các quy trình làm việc phổ biến: xây dựng & 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 feature flag, xem xét pull request, phê duyệt pipeline đang chờ xử lý, và nhiều hơn nữa.
Hoạt động ở mọi nơi. Transport stdio cho các máy khách cục bộ (Claude Desktop, Cursor, Devin Desktop), transport 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ừ token PAT và SAT, mặc định org/project là tùy chọn, và bộ lọc toolset 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 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 schema, không cập nhật prompt.

Đ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:

Đăng nhập vào tài khoản Harness của bạn
Đi tới Hồ sơ của tôi → Khóa API → + Khóa API mới
Tạo Token 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>
Lưu token ở nơi an toàn — bạn sẽ cần nó ở bước tiếp theo

Để biết hướng dẫn chi tiết, hãy xem Khởi động nhanh API Harness.

Khởi Động 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 endpoint đượ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 Harness Support bật/cấu hình cho từng tài khoản trước khi endpoint 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 (Được 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ừ token 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 được theo dõi tại [icon.png](icon.png) trong thư mục gốc của kho lưu trữ. Sao chép mcp-directory/manifest.json vào thư mục gốc của gói sau pnpm build để kho lưu trữ được tạo chứa manifest.json, icon.png, build/, package.json ở cấp gốc và node_modules/ cho môi trường production.

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

pnpm prepare:mcpb

Gói được staging được ghi vào dist/mcpb/ với các phụ thuộc production được cài đặt bằng bố cục phẳng của npm.

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

Transport 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.

Transport HTTP

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

Endpoint	Phương thức	Mô tả
`/mcp`	`POST`	Endpoint JSON-RPC MCP (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, elicitation)
`/mcp`	`DELETE`	Chấm dứt một phiên MCP đang hoạt động
`/mcp`	`OPTIONS`	Preflight CORS
`/health`	`GET`	Kiểm tra sức khỏe — trả về `{ "status": "ok", "sessions": <count> }`

Transport 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 tiêu đề đó.

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

Đặt HARNESS_MCP_AUTH_TOKEN cho bất kỳ triển khai dùng chung hoặc có thể truy cập từ xa nào. Khi được đặt, mọi yêu cầu POST, GET, và DELETE đến /mcp phải bao gồm Authorization: Bearer <token>.
Các ràng buộc 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 tường minh.
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 elicitation).
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à endpoint 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 phê duyệt tự động chặt chẽ 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ế độ Đ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 độc lập và vẫn có thể được sử dụng như một lớp cổng bổ sung ở tầng transport.

# 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 DNS-rebinding, 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 cổng/ proxy đảo ngược 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 từng 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 cách sử dụ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ợ endpoint 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 có một endpoint MCP từ xa dùng chung thay vì chạy npx harness-mcp-v2 hoặc tự lưu trữ transport HTTP.

Quan trọng: Xác thực MCP được lưu trữ sử dụng OAuth Nền tảng Harness. 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 cho 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.

Endpoint đượ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 SaaS Harness 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 đượ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"
      }
    }
  }
}

Xử lý sự cố npx ENOENT hoặc node: No such file or directory

Đây là lỗi khởi chạy tiến trình củ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 tường minh 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)

Node hệ thống: /usr/local/bin/npx

Claude Desktop (`claude_desktop_config.json`)

npx (không cần cài đặt)

{
  "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 (không cần cài đặt)

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 (không cần cài đặt, đượ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 (không cần cài đặt)

{
  "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 đã xây dựng của bạn:

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

Cổng MCP

Máy chủ MCP Harness hoàn toàn tương thích với MCP Gateways — các 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 chuẩn với cả hai phương thức truyền tải 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 nên dùng gateway?

Quản lý thông tin xác thực tập trung — không cần khóa API trong cấu hình agent
Quản trị và ghi nhật ký 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 agent thay vì N kết nối đến N máy chủ MCP
Kiểm soát truy cập — giới hạn 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ủ MCP Harness 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 thông qua phương thức truyền tải 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 upstream.

Kong

Sử dụng plugin AI MCP Proxy của Kong để hiển thị máy chủ MCP Harness thông qua 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, hãy sử dụng phương thức truyền tải mặc định. Đối với gateway dựa trên HTTP, hãy khởi động máy chủ với phương thức truyền tải http và trỏ gateway đến điểm cuối /mcp.

Docker

Xây dựng và chạy máy chủ dưới dạng 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 lên cụm Kubernetes bằng các manifest đượ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

Bản triển khai chạy 2 bản sao với các probe readiness/liveness, giới hạn tài nguyên và ngữ cảnh bảo mật không phải root. Service hiển thị cổng 80 nội bộ (nhắm đến 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 của dự án nếu có. Sao chép .env.example thành .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 trong cấu hình, dùng cho tất cả phiên) hoặc `multi-user` (chỉ HTTP, thông tin xác thực theo phiên qua header `x-harness-api-key` và tùy chọn `x-harness-account-id`)
`HARNESS_API_KEY`	Có*	--	Mã truy cập cá nhân (PAT) hoặc mã tài khoản dịch vụ (SAT) của Harness. Bắt buộc ở chế độ `single-user`. KHÔNG được đặt ở chế độ `multi-user`
`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 ở chế độ một người dùng; phiên nhiều người dùng có thể tự cung cấp qua `x-harness-account-id` khi khóa API không nhúng sẵn định danh này
`HARNESS_BASE_URL`	Không	`https://app.harness.io`	URL gốc API/UI của Harness cho triển khai stdio cục bộ hoặc HTTP tự lưu trữ. Đặt giá trị này cho các môi trường như `https://harness0.harness.io` khi bạn tự chạy máy chủ. Giá trị này không ảnh hưởng đến endpoint lưu trữ được quản lý `https://mcp.harness.io/mcp`
`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_`. Có thể là khóa admin Split kế thừa hoặc PAT/SAT Harness có quyền FME. Các cuộc gọi FME đi trực tiếp đến `api.split.io`, vì vậy 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 này. Không được đặt ở chế độ `multi-user`; FME phải dùng thông tin xác thực `x-harness-api-key` của từng phiên. Nếu không đặt, FME dự phòng sang `HARNESS_API_KEY` không phải placeholder cho phiên tự lưu trữ
`HARNESS_FME_BASE_URL`	Không	`https://api.split.io`	URL gốc API Split/FME Admin dùng cho tài nguyên `fme_`. URL HTTP yêu cầu `HARNESS_ALLOW_HTTP=true` cho phát triển cục bộ
`HARNESS_ORG`	Không	--	ID tổ chức. Dùng khi `org_id` không được chỉ định cho từng lệnh gọi công cụ. Nếu bỏ trống, `org_id` phải được cung cấp tường minh. 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. Dùng khi `project_id` không được chỉ định cho từng lệnh 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 thân yêu cầu HTTP tối đa 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 (số yêu cầu mỗi giây) tới 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 sẽ tải bộ công cụ mặc định. Hỗ trợ `+name` để bao gồm tường minh bộ công cụ chọn tham gia và `-name` để loại bỏ bộ mặc định (xem Lọc bộ công cụ)
`HARNESS_READ_ONLY`	Không	`false`	Chặn mọi thao tác biến đổi (tạo, cập nhật, xóa, thực thi). Chỉ cho phép liệt kê 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. Các thao tác ở mức rủi ro này hoặc thấp hơn sẽ tiến hành mà không cần xác nhận. Giá trị: `none`, `low_write`, `medium_write`, `high_write`, `all`. Xem Gợi hỏi
`HARNESS_SKIP_ELICITATION`	Không	`false`	Không dùng nữa — dùng `HARNESS_AUTO_APPROVE_RISK=all` thay thế. Giữ lại để 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ủ ép buộc HTTPS để bảo mật. Đặt thành `true` chỉ để 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 đè giá trị này tại thời điểm khởi tạo bằng `x-harness-pipeline-version: 0` hoặc `1`
`HARNESS_MCP_ALLOWED_HOSTS`	Không	--	Danh sách tên máy chủ được phép phân tách bằng dấu phẩy cho kiểm tra xác thực Host-header 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 tên miền proxy/tùy chỉnh tại đây
`HARNESS_MCP_AUTH_TOKEN`	Không	--	Mã Bearer bắt buộc trên các tuyến HTTP `/mcp` khi được đặt. Bắt buộc theo mặc định khi truyền tải HTTP liên kết với máy chủ không phải loopback
`HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP`	Không	`false`	Cho phép tường minh truyền tải HTTP không xác thực trên liên kết không phải loopback. Chỉ dùng phía sau một lớp đ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 được tin cậy để phân giải IP máy khách (Express `trust proxy`). Đặt bằng số proxy đứng trước máy chủ để giới hạn tốc độ theo từng IP dựa trên máy khách thực thay vì peer socket của 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 bằng dòng mới để thu thập cục bộ bền vững
`HARNESS_AUDIT_WEBHOOK_URL`	Không	--	Endpoint 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 gom vào lô trước khi xả đến webhook
`HARNESS_AUDIT_WEBHOOK_FLUSH_MS`	Không	`5000`	Thời gian tối đa giữ sự kiện kiểm toán trước khi xả đến webhook
`OTEL_EXPORTER_OTLP_ENDPOINT`	Không	--	Bật 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`	Nền tảng 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 ngoài qua HTTP, bắt buộc cho chế độ nhiều người dùng) hoặc `none` (tắt tìm kiếm ngữ nghĩa, dự phòng chỉ dùng scatter-gather từ khóa). Dùng `none` trong môi trường cách ly mạng hoặc khi không muốn tải mô hình lúc khởi động
`HARNESS_SEARCH_SERVICE_URL`	Không	--	URL gốc 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 dùng nhà cung cấp `remote`
`HARNESS_SEARCH_SERVICE_HEADERS`	Không	--	Đối tượng JSON chứa header gửi kèm mọi yêu cầu tới dịch vụ tìm kiếm từ xa. Hỗ trợ mọi phương thứ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`	No	`/tmp/hf-cache`	Thư mục cho bộ nhớ đệm mô hình `@huggingface/transformers` được sử dụng bởi nhà cung cấp tìm kiếm `local`. Hình ảnh Docker đã nạp 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`	No	`3`	Số lần tải xuống khối nhật ký đồng thời tối đa do `harness_diagnose` phát hành khi tìm nạp nhật ký cho các bước không thành công. Chỉ tăng nếu độ trễ chẩn đoán bị chi phối bởi thời gian tường đồng hồ tìm nạp nhật ký và pod có đủ 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 tán đế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 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 qua `tenant_id` — tài liệu/kiến thức tĩnh dùng `global`, dữ liệu thực thể theo tài khoản 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ộ bằng dịch vụ stub đi kèm (không cần 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ó dùng 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 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 thông báo:

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 dùng bởi 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à schema 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 theo dòng để thu thập cục bộ.
HARNESS_AUDIT_WEBHOOK_URL gửi các lô { "events": [...] } đến một webhook HTTPS, tùy chọn kèm HARNESS_AUDIT_WEBHOOK_TOKEN. Các lô thất bại được đưa lại hàng đợi với dung lượng giới hạn và cuối cùng bị loại bỏ kèm cảnh báo thay vì chặn việc 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ó nếu đã đượ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 best-effort; sự cố 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ẽ dựa vào HARNESS_ORG và HARNESS_PROJECT. harness_describe chỉ là siêu dữ liệu cục bộ và không 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 và template. Nếu resource_scope bị bỏ qua, registry dùng phạm vi mặc định của tài nguyên và các giá trị mặc định đã cấu hình, ngoại trừ các tài nguyên được đánh dấu phạm vi tùy chọn có thể bỏ qua org/project trừ khi được truyền tường minh. URL Harness cũng có thể tự động đặt phạm vi khi đường dẫn chứa ngữ cảnh cấp account hoặc cấp project.

Đầu ra có cấu trúc: Mọi công cụ khai báo một MCP outputSchema. 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 client nghiêm ngặt có thể xác thự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 dạng văn bản vẫn chứa tải trọng JSON gọn được trả về cho mọi client.

Công cụ	Mô tả
`harness_describe`	Khám phá các loại tài nguyên, thao tác và trường khả dụng. Không gọi API — trả về siêu dữ liệu registry cục bộ.
`harness_schema`	Lấy định nghĩa YAML/JSON Schema 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à các schema thực thể nhận biết phạm vi được lấy từ snapshot đóng gói hoặc NG `/yaml-schema`. Hỗ trợ khoan 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 một tài nguyên. Yêu cầu xác nhận từ người dùng qua elicitation. Có tính 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 các lần chạy pipeline, hãy dùng quy trình đầu vào thời gian chạy 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 bằng một truy vấn duy nhất. Dùng định tuyến ngữ nghĩa (nhúng ONNX cục bộ `all-MiniLM-L6-v2`, 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. Quay lại scatter-gather toàn bộ theo từ khóa 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 lượng 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 project 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

Dùng harness_schema trước khi tạo hoặc cập nhật tài nguyên dựa trên YAML để các 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ả.

Các schema đóng gói bao gồm pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1 và agent-pipeline.
Các 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 chúng.
Các snapshot thực thể được nhúng được dùng trước khi chúng khớp với tài khoản thời gian chạy; nếu không, công cụ sẽ dựa vào API Harness NG /yaml-schema và lưu kết quả vào bộ nhớ đệm.
Bỏ qua path để xem 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 một đị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 các snapshot thực thể được nhúng bằng pnpm sync-entity-schemas khi schema YAML thực thể Harness thay đổi.

Ví dụ về Công cụ

Khám phá những 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ê project trong một tổ chức:

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

Liệt kê pipeline trong một project:

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

Lấy một dịch vụ 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 một ứng dụng GitOps (kèm 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à nhật ký step lỗi:

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

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

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

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

{ "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ê các instance cơ sở dữ liệu cho một schema:

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

Lấy pipeline tạo tác LLM đã được phân giải cho một schema và instance:

{ "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 schema instance:

{
  "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ị)

Sử dụng trình tự này để giảm lỗi đầu vào tại thời điểm thực thi:

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 có giá trị.

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 (các 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).

Phím tắt codebase CI (chỉ dành cho pipeline run):

Phím tắt	Cấu trúc mở rộng
`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: việc mở rộng phím tắt bị bỏ qua khi inputs.build đã có sẵn (build tường minh được ưu tiên).

Thực thi lần chạy

harness_execute(resource_type="pipeline", action="run", resource_id="<pipeline_id>", ...)
Đối với pipeline dựa trên Git có YAML cần được tải từ một nhánh không mặc định, hãy truyền params.pipeline_branch (được gửi đến Harness dưới dạng pipelineBranchName):
```
{
  "resource_type": "pipeline",
  "action": "run",
  "resource_id": "deploy_app",
  "params": { "pipeline_branch": "feature/new-stage" },
  "inputs": { "branch": "main" },
  "wait": true
}
```

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.

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 pre-flight kèm các khóa dự kiến và bộ đầu vào được gợi ý. Bạn có thể kiểm tra các ánh xạ phím 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 runtime và cần chạy nó trên một shell pipeline 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ấp tài khoản và cấp pipeline Allow Dynamic Execution 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
  }
}

Ràng buộc:

body phải là một đối tượng có trường yaml. Các phần thân chuỗi thô bị từ chối bởi schema harness_execute công khai.
body.yaml có thể là chuỗi YAML hoặc đố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> runtime 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 stage 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 thành { "execution_id": "...", "status": "..." } và bao gồm liên kết thực thi openInHarness khi dữ liệu phạm vi có sẵn.

Nếu Harness từ chối lần chạy vì chưa đượ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 lần 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 dựa trên Git, hoặc các giá trị trigger/runtime khó tái dựng 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 thành:

executionId - ID thực thi kế hoạch từ resource_id.
inputSetYaml - YAML đầu vào runtime đã hợp nhất được sử dụng cho lần chạy, hoặc null.
inputSetTemplateYaml - template đầ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 dựa trên 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 lần thực thi đạt trạng thái cuối. Điều này giữ 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 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, giảm dần 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 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ỏ đến 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 bằng 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

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 cần 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 dựa trên 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 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 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 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 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 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 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 connector:

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

Xóa trigger:

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

Liệt kê input sets 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 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 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 input set:

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

Các loại tài nguyên

224 loại tài nguyên được tổ chức trong 38 toolset. 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
`approval_instance`	x					`approve`, `reject`

Chỉ một loại tài nguyên YAML pipeline được tải khi khởi động. Theo mặc định, HARNESS_PIPELINE_VERSION=0 hiển thị pipeline và ẩn pipeline_v1; đặt HARNESS_PIPELINE_VERSION=1 để hiển thị pipeline_v1 và ẩn pipeline. Trong chế độ HTTP, hãy bao gồm x-harness-pipeline-version: 0 hoặc 1 trong yêu cầu initialize để chọn phiên bản cho phiên đó.

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`

Bí mật

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
`delegate_token`	x	x	x		x	`revoke`, `get_delegates`

Kho mã nguồn

Loại tài nguyên	Danh sách	Xem	Tạo	Cập nhật	Xóa	Thực thi hành động
`repository`	x	x	x	x
`branch`	x	x	x		x
`commit`	x	x	x			`diff`, `diff_stats`
`file_content`		x				`blame`
`tag`	x		x		x
`repo_rule`	x	x
`space_rule`	x	x

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

Kho lưu trữ Tạo tác (Artifact Registries)

Loại tài nguyên	Danh sách	Xem
`registry`	x	x
`artifact`	x
`artifact_version`	x
`artifact_file`	x

Kho Tệp (File Store)

Loại tài nguyên	Danh sách	Xem	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 của Harness File Store 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 của Harness File Store để 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 ký tự "Root" cho gốc của phạm vi đã chọn.
Việc tạo FILE yêu cầu chính xác một trong hai: 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 cho các bản 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 của 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 với params.folder_name, hoặc params.file_store_id/params.folder_identifier cộng với params.folder_name) hoặc một FileStoreNode đầy đủ body 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 (Templates)

Loại tài nguyên	Danh sách	Xem	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 về mẫu sử dụng các đường dẫn dịch vụ Harness Template (/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 việc 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 (Dashboards)

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

Database DevOps

Loại tài nguyên	Danh sách	Xem	Tạo	Cập nhật	Xóa
`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 mặc định và chủ yếu theo phạm vi dự án. Bắt đầu với iacm_workspace để tì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 tái sử dụng ở phạm vi tài khoản, tổ chức hoặc dự án. Sổ đăng ký mô-đun theo phạm vi tài khoản.

Tạo/cập nhật iacm_workspace chỉ trả về { policy_evaluation } — hãy theo dõi bằng harness_get để lấy không gian làm việc. Tạo/cập nhật iacm_variable_set trả về chính tài nguyên VariableSet. Cập nhật variable-set 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 (bắt buộc terraform_variables / environment_variables khi cập nhật; bỏ qua/để trống sẽ xóa các trình kết nối và tệp biến). Các ghi là medium_write và yêu cầu xác nhận (elicitation hoặc confirm: true).

RBAC của variable-set (iac_variableset_*) hiện đang ở trạng thái Experimental trong Harness — các kiểm tra truy cập luôn cho phép cho đến khi iac-server kích hoạt thực thi. MCP vẫn chuyển tiếp PAT/SAT của người gọi mà không thay đổi.

Loại tài nguyên	Danh sách	Xem	Tạo	Cập nhật
`iacm_workspace`	x	x	x	x
`iacm_variable_set`	x	x	x	x
`iacm_resource`	x
`iacm_module`	x	x
`iacm_workspace_costs`	x
`iacm_activity_resource_change`	x

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

harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") để tìm không gian làm việc.
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 }.
harness_get(resource_type="iacm_workspace", workspace_id="...") để lấy không gian làm việc đã tạo/cập nhật.
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 tái sử dụng — phản hồi là tài nguyên VariableSet.
harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") để kiểm tra các tài nguyên Terraform, đầu ra và nguồn dữ liệu.
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.
harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") để kiểm tra các khác biệt tài nguyên trước/sau cho một hoạt động plan, apply hoặc destroy.

Các phản hồi danh sách IaCM hiển thị page_count dưới dạng số lượng chỉ cho trang hiện tại (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 tổng số 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	Xem	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 (Pull Requests)

Loại tài nguyên	Danh sách	Xem	Tạo	Cập nhật	Thực thi hành động
`pull_request`	x	x	x	x	`close`, `merge`
`pr_reviewer`	x		x		`submit_review`
`pr_comment`	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 chuyên dụng của Harness Code; gửi các chỉnh sửa tiêu đề/mô tả trong một lệnh gọi cập nhật riêng.

Cờ Tính năng (Feature Flags)

Loại tài nguyên	Danh sách	Xem	Tạo	Cập nhật	Xóa	Thực thi hành động
`fme_workspace`	x
`fme_environment`	x
`fme_feature_flag`	x	x	x	x	x	`kill`, `restore`, `archive`, `unarchive`
`fme_feature_flag_definition`		x	x	x
`fme_rollout_status`	x
`fme_rule_based_segment`	x	x	x		x
`fme_rule_based_segment_definition`	x			x		`enable`, `disable`, `change_request`
`fme_traffic_type`	x
`fme_identity`			x	x
`fme_standard_segment`	x	x
`fme_segment_keys`	x			x
Tài nguyên FME (Split.io) — Các tài nguyên `fme_`* sử dụng API Split.io (`api.split.io`) và được phạm vi theo ID không gian làm việc thay vì org/project. Trong chế độ người dùng đơn/tự lưu trữ, xác thực sử dụng mã thông báo 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 cũ 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 trong mỗi phiên. Thông tin xác thực OAuth/định tuyến dịch vụ được lưu trữ cho các API nền tảng Harness không xác thực được các yêu cầu Split.io trực tiếp. `fme_feature_flag` hỗ trợ quản lý vòng đời đầy đủ: 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/archive/unarchive. Sử 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 các phân đoạn tiêu chuẩn và thêm khóa thành viên. `fme_rule_based_segment` cung cấp CRUD cho các phân đoạn nhắm mục tiêu, trong khi `fme_rule_based_segment_definition` quản lý các quy tắc phân đoạn theo môi trường cụ thể 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	Thực thi hành động
`gitops_agent`	x	x
`gitops_application`	x	x	`sync`
`gitops_cluster`	x	x
`gitops_repository`	x	x
`gitops_applicationset`	x	x
`gitops_repo_credential`	x	x
`gitops_app_event`	x
`gitops_pod_log`		x
`gitops_managed_resource`	x
`gitops_resource_action`	x
`gitops_dashboard`		x
`gitops_app_resource_tree`		x

Chaos Engineering

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`
`chaos_probe`	x	x	x		x	`enable`, `verify`
`chaos_probe_in_run`	x
`chaos_probe_template`	x	x			x
`chaos_infrastructure`	x
`chaos_k8s_infrastructure`	x	x				`check_health`
`chaos_environment`	x
`chaos_hub`	x	x	x	x	x
`chaos_hub_fault`	x
`chaos_fault`	x	x			x
`chaos_fault_template`	x	x			x
`chaos_fault_experiment_run`	x
`chaos_action`	x	x			x
`chaos_action_template`	x	x			x
`chaos_loadtest`	x	x	x		x	`run`, `stop`
`chaos_application_map`	x	x
`discovered_namespace`	x
`discovered_service`	x
`discovered_network_map`	x
`chaos_guard_condition`	x	x			x
`chaos_guard_rule`	x	x			x	`enable`
`chaos_recommendation`	x	x
`chaos_risk`	x	x
`chaos_dr_test`	x		x
`scanned_risk`	x	x				`occurrences`, `summary_by_service`
`chaos_risk_rule`	x	x
`chaos_risk_scan`	x	x	x	x	x	`retry`, `abort`, `report`, `report_download`, `heatmap`

Cloud Cost Management (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

Software Engineering Insights (SEI)

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 đội ngũ/cây tổ chức và thông tin chi tiết AI.

Loại tài nguyên	Danh sách	Lấy	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 get
`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

Software Supply Chain Assurance (SCS)

Resource Type	List	Get
`scs_artifact_source`	x
`artifact_security`	x	x
`scs_artifact_component`	x
`scs_artifact_remediation`		x
`scs_chain_of_custody`		x
`scs_compliance_result`	x
`code_repo_security`	x	x
`scs_sbom`		x

Evidence Vault

Evidence Vault 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. Các bộ lọc văn bản tự do số ít (pipeline, artifact đơn lẻ, gitoid) sử dụng search_term; ràng buộc Tên bổ sung sử dụng filters.subject_name; mã băm nội dung subject sử dụng filters.subject_digest. Get tra cứu theo gitoid_sha256 và yêu cầu org_id/project_id (từ hàng trong danh sách). Download (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.

Resource Type	List	Get	Create	Update	Delete	Execute Actions
`attestation`	x	x				`download`

Security Testing Orchestration (STO)

Resource Type	List	Create	Execute Actions
`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 là 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ỏ tường minh (ví dụ filters: { "status": "Pending", "size": 5 }) và theo dõi _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à status tường minh như Pending, Approved, Rejected, Expired hoặc Canceled.
Sử dụng harness_execute với action="approve" và 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 nội bộ endpoint thăng cấp STO. Máy chủ tự động điền body.approver_id từ người dùng đã xác thực khi bị 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ị bỏ trống.
Không có hành động thực thi promote riêng biệt. Sử dụng action="approve" với body.scope không phải CURRENT khi kết quả được yêu cầu là phê duyệt ở phạm vi tài khoản, tổ chức hoặc dự án.

Access Control

Resource Type	List	Get	Create	Delete
`user`	x	x
`user_group`	x	x	x	x
`service_account`	x	x	x	x
`role`	x	x	x	x
`role_assignment`	x		x
`resource_group`	x	x	x	x
`permission`	x

Governance

Resource Type	List	Get	Create	Update	Delete
`policy`	x	x	x	x	x
`policy_set`	x	x	x	x	x
`policy_evaluation`	x	x

Deployment Freeze

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

Service Overrides

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

Settings

Resource Type	List	Get	Create	Update	Delete	Execute Actions
`setting`	x

MCP Prompts

DevOps

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 đã hết số lần thử lại, cung cấp các liên kết sâu Harness UI tới 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 execution ID, pipeline ID, hoặc Harness URL. Lấy thông tin chi tiết 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à đề 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 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 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ó để lấy 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ó, thu thập yêu cầu, tạo spec agent YAML bằng schema agent-pipeline, 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 service mới với các môi trường và 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) với phân loại Elite/Cao/Trung bình/Thấp 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 service với fault injection, probes, 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 feature flag theo tiến trình trên 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 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à xử lý sự cố hạ tầng	`projectId` (tùy chọn)
`developer-portal-scorecard`	Xem xét IDP scorecards cho các service và xác định các 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 mức 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 service, 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à biện pháp 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 biện pháp 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ờ 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 rõ ràng về phạm vi và thời hạn	`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, các tài khoản có quyền quá mức, 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

Lời nhắc	Mô tả	Tham số
`code-review`	Xem xét một pull request — phân tích diff, commits, checks và comments để 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 cũ hoặc đã hợp nhất để xóa	`repoId` (bắt buộc), `projectId` (tùy chọn)

MCP Resources

URI tài nguyên	Mô tả	Loại MIME
`pipeline:///{pipelineId}`	Định nghĩa YAML pipeline	`application/x-yaml`
`pipeline:///{orgId}/{projectId}/{pipelineId}`	Pipeline YAML (với 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 template Harness	`application/schema+json`
`schema:///trigger`	Lược đồ JSON trigger Harness	`application/schema+json`
`schema:///pipeline_v1` (Alpha)	Lược đồ JSON pipeline V1 Harness (đị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`

Lọc Toolset

Theo mặc định, 38 trong số 39 toolset được bật. Một toolset 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.

Thêm toolset với tiền tố `+`

Sử dụng tiền tố + để bao gồm rõ ràng các toolset 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 toolset mặc định

Sử dụng tiền tố - để loại trừ các toolset 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 toolset được liệt kê mới được bật:

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

Tên toolset có sẵn:

Bộ công 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
`gitops`	gitops_agent, gitops_application, gitops_cluster, gitops_repository, gitops_applicationset, gitops_repo_credential, gitops_app_event, gitops_pod_log, gitops_managed_resource, gitops_resource_action, gitops_dashboard, gitops_app_resource_tree
`chaos`	chaos_experiment, chaos_experiment_run, chaos_experiment_variable, chaos_component_variable, chaos_input_set, chaos_experiment_template, chaos_probe, chaos_probe_in_run, chaos_probe_template, chaos_infrastructure, chaos_k8s_infrastructure, chaos_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_application_map, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan
`ccm`	cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment
`sei`	sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric
`scs`	scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom
`evidence-vault`	attestation
`sto`	security_issue, security_issue_filter, security_exemption, remediation_diff
`dbops`	database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline
`access_control`	user, user_group, service_account, role, role_assignment, resource_group, permission
`governance`	policy, policy_set, policy_evaluation
`freeze`	freeze_window, global_freeze
`overrides`	service_override
`settings`	setting
`knowledge-graph`	kg_queryable_type_summary, kg_grammar, hql_query
`semantic-layer`	kg_type, kg_related_type
`ai-evals`	eval_dataset, eval_dataset_item, evaluation, eval_run, eval_run_item, eval_run_by_eval, eval_metric, eval_metric_set, eval_metric_set_entry, eval_suite, eval_suite_evaluation, eval_suite_run, eval_target, eval_annotation, eval_analytics, eval_git_settings, eval_registry_item, eval_git_registration, online_eval
`iacm`	iacm_workspace, iacm_variable_set, iacm_resource, iacm_module, iacm_workspace_costs, iacm_activity_resource_change
`ansible` (tùy chọn tham gia)	ansible_inventory, ansible_playbook, ansible_host, ansible_host_activity, ansible_activity

Kiến trúc

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

Cách hoạt động

Công cụ (Tools) là các động từ chung: harness_list, harness_get, v.v. Chúng nhận tham số resource_type để định tuyến đến đúng endpoint API.
Registry ánh xạ mỗi resource_type tới 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ố path/query và logic trích xuất phản hồi.
Dispatch phân giải định nghĩa tài nguyên, xây dựng yêu cầu HTTP (thay thế path, tham số query, tiêm account/org/project 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.
Lọc toolset (HARNESS_TOOLSETS) kiểm soát định nghĩa tài nguyên nào được nạp vào registry khi khởi động.
Đầu ra có cấu trúc được khai báo bằng MCP outputSchema; harness_list chuyển đổi mảng và các wrapper danh sách phổ biến thành structuredContent dạng đối tượng cho các client nghiêm ngặt.
Deep link đượ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.
Chế độ gọn (Compact mode) loại bỏ metadata dài dòng khỏi kết quả danh sách, chỉ giữ lại các trường có thể thao tác (danh tính, trạng thái, loại, dấu thời gian, deep link) để 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 một toolset 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 đó import 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

Elicitation

Các công cụ ghi (harness_create, harness_update, harness_delete, harness_execute) sử dụng MCP elicitation để 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) được thực hiện â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 điều 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 hệ thống.

Cách hoạt động:

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 rủi ro thấp không hiển thị lời nhắc.
Máy chủ gửi yêu cầu elicitation đến client kèm tóm tắt thao tác và hộp kiểm confirm (được chọn theo mặc định).
Người dùng xem chi tiết và nhấp Chấp nhận (với confirm được chọn) hoặc Từ chối / Hủy.
Nếu được chấp nhận với confirm: true, thao tác sẽ tiếp tục. 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 (việc từ chối rõ ràng là có tính quyết định và không bị bỏ qua bởi confirm: true trên lời gọi công cụ).

Hỗ trợ client:

Client	Hỗ trợ Elicitation
Cursor	Có
VS Code (Copilot)	Có
Claude Desktop	Chưa
Devin Desktop	Chưa
MCP Inspector	Có

Hành vi elicitation thay đổi theo mức rủi ro của thao tác khi client không hỗ trợ:

Mức rủi ro	Client hỗ trợ elicitation	`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ó tác dụng ở 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 schema). Việc 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ó tính quyết định và không bị bỏ qua bởi `confirm: true` trên lời gọi công cụ. Việc chấp nhận thiếu trường `confirm` được coi là client không hiển thị được lời nhắc hữu 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 kèm 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ỳ (ở mức hoặc dưới `HARNESS_AUTO_APPROVE_RISK`)	bất kỳ	bất kỳ	Tự động phê duyệt mà không cần nhắc

Nếu elicitInput thất bại khi chạy (lỗi truyền tải, phương thức không được hỗ trợ) cho thao tác medium_write+, lời 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 client không thể hiển thị lời nhắc hoặc trả về một lần chấp nhận suy biến ({action: "accept"} không có trường xác nhận), nhưng nó không ghi đè việc từ chối/hủy rõ ràng từ một client đã hoàn tất quá trình bắt tay elicitation.

Chế độ tự động (Autonomous Mode)

Chế độ tự động có nghĩa là máy chủ tiến hành mọi thao tác — bao gồm cả ghi và các 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à mức trần ở cấp độ triển khai: một khi đã đặt, các phiên riêng lẻ không thể vượt quá mức đó (mặc dù chúng có thể chọn ngưỡng nghiêm ngặt hơn cho từng phiên thông qua header x-harness-auto-approve-risk).

Hoặc trong cấu hình client 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 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ị	Điều đượ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ả cá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 mọi 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 để giới hạn 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ạ tới 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ề metadata (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 elicitation 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 elicitation MCP trước khi tiến hành (xem Elicitation). 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 chặn khi không xác nhận được. Nếu không thể lấy 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 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. Client API Harness thực thi giới hạn 10 yêu cầu/giây để tránh chạm giới hạn tốc độ thượng nguồn.
Giới hạn phân trang được thực thi. Các truy vấn danh sách được giới hạn ở 10.000 mục tổng cộng 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 ràng buộc với 127.0.0.1 theo mặc định — không thể truy cập từ mạng.
Không ghi log stdout. Tất cả log được ghi vào stderr để tránh làm hỏng truyền tải stdio JSON-RPC.

Kỹ năng bổ trợ

Máy chủ Harness MCP kết hợp tốt với Harness Skills — một bộ sưu tập các kỹ năng Claude Code có sẵn (lệnh gạch chéo) được thiết kế cho các quy trình 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à nhiều hơn nữa mà không cần viết lời nhắc tùy chỉnh.

Xử lý sự cố & Các lỗi thường gặp

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 có 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ố vận chuyển CLI 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 dạng	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ó tiêu đề phiên	Gửi `initialize` trước, rồi 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 tiêu đề mới
HTTP `405 Method Not Allowed` trên `/mcp`	Phương thức không được hỗ trợ cho điểm cuối 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 phần thân yêu cầu vượt quá `HARNESS_MAX_BODY_SIZE_MB`	Xác thực kích thước/hình dạng tải trọng 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 có 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 từng 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ó ý định thực hiện thao tác ghi
Quá trình chạy pipeline thất bại trước khi khởi động 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ải `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
Lệnh viết tắt CI của 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 lệnh viết tắt được bỏ qua có chủ đích	Xóa `inputs.build` để sử dụng mở rộng lệnh viết tắt, hoặc giữ cấu trúc `build` tường minh đầy đủ
Quá trình 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 `pipelineBranchName` 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 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ì vượt 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 vượt qua một sự từ chối rõ ràng. 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 thoái hóa	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 tải trọng YAML đầy đủ	Cung cấp chuỗi `template_yaml` đầy đủ trong `body`; đối với 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

Harness

Bạn có thể làm gì với Harness MCP?

Tài liệu

Máy chủ MCP Harness 2.0

Vì Sao Nên Dùng Máy Chủ MCP Này

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

Khởi Động Nhanh

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

Tùy chọn 1: npx (Được khuyến nghị)

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

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

Gói thư mục MCP Anthropic

Sử dụng CLI

Transport HTTP

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

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

Harness MCP được lưu trữ

Claude Desktop (claude_desktop_config.json)

Claude Code (qua claude mcp add)

Cursor (.cursor/mcp.json)

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

Cổng MCP

Docker MCP Gateway

Portkey

LiteLLM

Envoy AI Gateway

Kong

Các Gateway Khác

Docker

Kubernetes

Cấu hình

Tìm kiếm ngữ nghĩa

Thực thi HTTPS

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

Tham chiếu Công cụ

Quy trình Tra cứu Schema

Ví dụ về Công cụ

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

Thực thi Pipeline động

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

Chế độ chờ thực thi Pipeline

Chế độ lưu trữ Pipeline

Các loại tài nguyên

Nền tảng

Pipelines

AI Agents

Services

Environments

Connectors

Cơ sở hạ tầng

Bí mật

Nhật ký thực thi

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

Delegates

Kho mã nguồn

Kho lưu trữ Tạo tác (Artifact Registries)

Kho Tệp (File Store)

Mẫu (Templates)

Bảng điều khiển (Dashboards)

Database DevOps

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

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

Yêu cầu Kéo (Pull Requests)

Cờ Tính năng (Feature Flags)

GitOps

Chaos Engineering

Cloud Cost Management (CCM)

Software Engineering Insights (SEI)

Software Supply Chain Assurance (SCS)

Evidence Vault

Security Testing Orchestration (STO)

Access Control

Governance

Deployment Freeze

Service Overrides

Settings

MCP Prompts

DevOps

FinOps

DevSecOps

Claude Desktop (`claude_desktop_config.json`)

Claude Code (qua `claude mcp add`)

Cursor (`.cursor/mcp.json`)

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

Thêm toolset với tiền tố `+`