Harness

Harness MCP Server 2.0

เซิร์ฟเวอร์ MCP (Model Context Protocol) ที่ให้เอเจนต์ AI เข้าถึงแพลตฟอร์ม Harness.io ได้อย่างเต็มรูปแบบผ่านเครื่องมือรวม 11 รายการและประเภททรัพยากร 255 ประเภท

เหตุผลที่ควรใช้ MCP Server นี้

เซิร์ฟเวอร์ MCP ส่วนใหญ่จะจับคู่เครื่องมือหนึ่งรายการต่อ API endpoint หนึ่งรายการ สำหรับแพลตฟอร์มที่กว้างขวางอย่าง Harness นั่นหมายถึงเครื่องมือมากกว่า 240 รายการ — และ LLM จะเลือกเครื่องมือได้แย่ลงเมื่อจำนวนเพิ่มมากขึ้น Context windows เต็มไปด้วย schemas และทุก endpoint ใหม่หมายถึงโค้ดใหม่

เซิร์ฟเวอร์นี้ถูกสร้างขึ้นด้วยวิธีที่แตกต่าง:

• เครื่องมือ 11 รายการ, ประเภททรัพยากร 255 ประเภท ระบบ dispatch แบบ registry-based จะส่ง harness_list, harness_get, harness_create ฯลฯ ไปยังทรัพยากร Harness ใดก็ได้ — pipelines, services, environments, orgs, projects, feature flags, ข้อมูลค่าใช้จ่าย และอื่นๆ อีกมากมาย LLM เลือกจากเครื่องมือ 11 รายการแทนที่จะเป็นหลายร้อยรายการ
• ครอบคลุมแพลตฟอร์มทั้งหมด ชุดเครื่องมือเริ่มต้น 41 รายการครอบคลุม CI/CD, GitOps, Feature Flags, Cloud Cost Management, Security Testing, Chaos Engineering, Database DevOps, Internal Developer Portal, Software Supply Chain, Infrastructure as Code Management, Release Management, Governance, Service Overrides, Knowledge Graph และอื่นๆ รองรับ Ansible และ observability-evaluation แบบ opt-in เมื่อจำเป็น
• เวิร์กโฟลว์หลายโปรเจกต์พร้อมใช้งานทันที เอเจนต์ค้นพบ organizations และ projects แบบไดนามิก — ไม่จำเป็นต้องใช้ env vars แบบ hardcoded ถามว่า "แสดง executions ที่ล้มเหลวในทุกโปรเจกต์" แล้วเอเจนต์จะนำทางไปยังลำดับชั้นบัญชีทั้งหมดได้
• เทมเพลต prompt 35 รายการ Prompt ที่สร้างไว้ล่วงหน้าสำหรับเวิร์กโฟลว์ทั่วไป: สร้างและ deploy แอปแบบ end-to-end, แก้ไขปัญหา failed pipelines, ตรวจสอบ DORA metrics, จัดการลำดับความสำคัญของ vulnerabilities, ปรับต้นทุนคลาวด์ให้เหมาะสม, ตรวจสอบ access control, วางแผน feature flag rollouts, ตรวจสอบ pull requests, อนุมัติ pipelines ที่รออยู่ และอื่นๆ
• ใช้งานได้ทุกที่ Stdio transport สำหรับไคลเอ็นต์ในเครื่อง (Claude Desktop, Cursor, Devin Desktop), HTTP transport สำหรับการ deploy แบบ remote/shared, พร้อมใช้งานกับ Docker และ Kubernetes
• เริ่มต้นโดยไม่ต้องตั้งค่า เพียงให้ Harness API key เท่านั้น Account ID ถูกดึงออกจาก PAT และ SAT tokens โดยอัตโนมัติ ค่าเริ่มต้น org/project เป็นตัวเลือก และการกรองชุดเครื่องมือช่วยให้คุณเปิดเผยเฉพาะสิ่งที่คุณต้องการ
• ออกแบบให้ขยายได้ การเพิ่มทรัพยากร Harness ใหม่หมายถึงการเพิ่มไฟล์ข้อมูลแบบ declarative — ไม่ต้องลงทะเบียนเครื่องมือใหม่ ไม่มีการเปลี่ยนแปลง schema ไม่ต้องอัปเดต prompt

ข้อกำหนดเบื้องต้น

ก่อนติดตั้งหรือรันเซิร์ฟเวอร์ คุณต้องมี Harness API key:

1. เข้าสู่ระบบ บัญชี Harness ของคุณ
2. ไปที่ My Profile → API Keys → + New API Key
3. สร้าง Token ใหม่ภายใต้ API key — จะสร้าง PAT หรือ SAT ในรูปแบบ <prefix>.<accountId>.<tokenId>.<secret>
4. เก็บ token ไว้ในที่ปลอดภัย — คุณจะต้องใช้ในขั้นตอนถัดไป

สำหรับคำแนะนำโดยละเอียด ดู Harness API Quickstart

เริ่มต้นใช้งานอย่างรวดเร็ว

ตัวเลือก 0: Hosted Harness MCP

หากบัญชี Harness ของคุณเปิดใช้งานบริการ hosted MCP ไคลเอ็นต์ที่รองรับ remote MCP servers สามารถเชื่อมต่อโดยตรงกับ managed endpoint แทนการรันเซิร์ฟเวอร์ในเครื่อง

สำคัญ: บริการ hosted MCP ใช้ Harness Platform OAuth ไม่ใช่ HARNESS_API_KEY และต้องเปิดใช้งาน/กำหนดค่าต่อบัญชีโดย Harness Support ก่อนจึงจะใช้ endpoint ได้

ดู Hosted Harness MCP สำหรับตัวอย่างการกำหนดค่า

ตัวเลือก 1: npx (แนะนำ)

ไม่ต้องติดตั้ง — เพียงรัน:

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

หรือกำหนดค่า API key ในไคลเอ็นต์ AI ของคุณ (ดู Client Configuration ด้านล่าง)

# 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

หมายเหตุ: Account ID ถูกดึงออกจาก PAT และ SAT tokens โดยอัตโนมัติ (pat.<accountId>... หรือ sat.<accountId>...) ดังนั้น HARNESS_ACCOUNT_ID จำเป็นเฉพาะสำหรับ API keys ที่ไม่มี segment บัญชีฝังอยู่

ตัวเลือก 2: การติดตั้งแบบ Global

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

ตัวเลือก 3: สร้างจาก Source

สำหรับการพัฒนาหรือการปรับแต่ง:

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

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

ชุดรวม Anthropic MCP Directory

Manifest ของชุดรวม MCPB อยู่ใน [mcp-directory/](mcp-directory/) และไอคอนชุดรวมขนาด 512×512 ถูกติดตามที่ [icon.png](icon.png) ในโฟลเดอร์รากของ repository ไฟล์เก็บถาวรที่แพ็กเกจประกอบด้วย manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json และ node_modules/ สำหรับ production

เพื่อให้ไฟล์เก็บถาวรมีขนาดเล็ก ให้สร้างแพ็กเกจ MCPB จากโฟลเดอร์ staging:

pnpm prepare:mcpb

โฟลเดอร์ staging ถูกเขียนไปยัง dist/mcpb/ พร้อม dependencies สำหรับ production ที่ติดตั้งจาก npm-shrinkwrap.json โดยใช้ flat layout ของ npm CLI MCPB อย่างเป็นทางการที่ pinned ตรวจสอบและสร้าง dist/harness-mcp-server-<version>.mcpb

แท็กเวอร์ชันที่ตรงกับ v*.*.* จะเผยแพร่ชุดรวมนั้นไปยัง GitHub Release ที่เกี่ยวข้องโดยอัตโนมัติ หากต้องการ backfill release ที่มีอยู่โดยไม่เผยแพร่ npm ใหม่ ให้รันเวิร์กโฟลว์ Release ด้วยตนเองพร้อม input release_tag (ตัวอย่างเช่น v3.2.20) เวิร์กโฟลว์จะ checkout และสร้างแท็กนั้นอย่างแม่นยำก่อนแทนที่เฉพาะ asset MCPB ที่มีเวอร์ชัน

การใช้งาน CLI

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

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

Transport เริ่มต้นเป็น stdio หากไม่ได้ระบุ ใช้ http สำหรับการ deploy แบบ remote/shared

HTTP Transport

เมื่อรันในโหมด HTTP เซิร์ฟเวอร์จะเปิดเผย:

Endpoint	Method	คำอธิบาย
/mcp	POST	MCP JSON-RPC endpoint (คำขอ initialize + session)
/mcp	GET	สตรีม SSE สำหรับข้อความที่เซิร์ฟเวอร์เริ่ม (ความคืบหน้า, การขอข้อมูล)
/mcp	DELETE	ยกเลิก session MCP ที่ใช้งานอยู่
/mcp	OPTIONS	CORS preflight
/health	GET	การตรวจสอบสุขภาพ — คืนค่า { "status": "ok", "sessions": <count> }
/.well-known/oauth-protected-resource	GET	เมตาดาต้า RFC 9728 เมื่อ HARNESS_MCP_MODE=oauth
/.well-known/oauth-protected-resource/mcp	GET	เมตาดาต้า RFC 9728 แบบรับรู้ path สำหรับทรัพยากร /mcp เริ่มต้น

HTTP transport ทำงานใน โหมด session-based session MCP ใหม่ถูกสร้างขึ้นเมื่อ initialize เซิร์ฟเวอร์คืนค่า header mcp-session-id และคำขอถัดไปสำหรับ session นั้นต้องรวม header เดียวกัน

ข้อจำกัดการทำงานในโหมด HTTP:

• ตั้งค่า HARNESS_MCP_AUTH_TOKEN สำหรับการ deploy แบบ shared หรือ remotely reachable สำหรับผู้ใช้คนเดียวและหลายผู้ใช้ เมื่อตั้งค่า ทุกคำขอ POST, GET และ DELETE ไปยัง /mcp ต้องรวม Authorization: Bearer <token>
• โหมด OAuth ยอมรับ access tokens ของ HarnessID แทน HARNESS_MCP_AUTH_TOKEN และสามารถผูกกับ address ที่ไม่ใช่ loopback โดยไม่ต้อง opt-out แบบไม่มีการตรวจสอบสิทธิ์
• การผูกแบบ non-loopback สำหรับผู้ใช้คนเดียวและหลายผู้ใช้ต้องใช้ HARNESS_MCP_AUTH_TOKEN โดยค่าเริ่มต้น หากต้องการรันแบบไม่มีการตรวจสอบสิทธิ์บนอินเทอร์เฟซที่ไม่ใช่ loopback ให้ตั้งค่า HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true อย่างชัดเจน
• POST /mcp โดยไม่มี mcp-session-id ต้องเป็นคำขอ initialize
• POST /mcp, GET /mcp และ DELETE /mcp สำหรับ session ที่มีอยู่ต้องใช้ header mcp-session-id
• GET /mcp ใช้สำหรับการแจ้งเตือน SSE (การอัปเดตความคืบหน้าและ prompt การขอข้อมูล)
• Session ที่ไม่มีการใช้งานจะถูกเก็บหลังจาก MCP_SESSION_TTL_MS มิลลิวินาทีเมื่อไม่มีคำขอหรือสตรีม SSE ที่ใช้งานอยู่ (ค่าเริ่มต้น 1800000 หรือ 30 นาที)
• GET /health เป็น endpoint เดียวที่ไม่ใช่ MCP
• ขนาด body ของคำขอถูกจำกัดโดย HARNESS_MAX_BODY_SIZE_MB (ค่าเริ่มต้น 10 MB)
• ตั้งค่า x-harness-pipeline-version: 0 หรือ 1 บนคำขอ initialize เพื่อเลือกทรัพยากร pipeline V0 หรือ V1 สำหรับ session HTTP นั้น
• ตั้งค่า x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all บนคำขอ initialize เพื่อเลือกเกณฑ์การอนุมัติอัตโนมัติต่อ session ที่เข้มงวดยิ่งขึ้น เซิร์ฟเวอร์จำกัดค่านี้ที่ระดับ deployment HARNESS_AUTO_APPROVE_RISK ดังนั้น session สามารถลดแต่ไม่สามารถขยายเพดานการอนุมัติที่กำหนดค่าไว้

โหมด HarnessID OAuth

ตั้งค่า HARNESS_MCP_MODE=oauth เพื่อให้ไคลเอ็นต์ MCP ระยะไกลค้นพบ HarnessID และทำ OAuth 2.1 Authorization Code with PKCE ให้สมบูรณ์ โหมด OAuth ใช้งานได้เฉพาะกับ HTTP transport เท่านั้น ค่าเริ่มต้นสำหรับ Production HarnessID, ทรัพยากร MCP และการกำหนดเส้นทาง API ของ Harness ถูกสร้างไว้แล้ว:

HARNESS_MCP_MODE=oauth

ค่าเริ่มต้นนี้คือ issuer https://id.harness.io/idp/realms/HarnessIDP, ทรัพยากร https://mcp.harness.io/mcp, ไคลเอ็นต์ OAuth mcp-client และฐาน API ของ Harness https://mcp.harness.io/cli กำหนดค่าใหม่เฉพาะสำหรับ QA, การพัฒนาท้องถิ่น หรือสภาพแวดล้อม Harness อื่น

HARNESS_API_KEY ต้องไม่ถูกตั้งค่าในโหมดนี้ HARNESS_MCP_OAUTH_JWKS_URI เริ่มต้นเป็น <issuer>/protocol/openid-connect/certs และ HARNESS_ACCOUNT_ID ไม่จำเป็นเพราะบัญชีมาจาก token

เซิร์ฟเวอร์เผยแพร่เมตาดาต้าทรัพยากรที่ได้รับการป้องกัน RFC 9728 และคืนค่า challenge นี้เมื่อไคลเอ็นต์ยังไม่ได้ตรวจสอบสิทธิ์:

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

เซิร์ฟเวอร์ตรวจสอบลายเซ็น RS256 ของ access token HarnessID, iss, วันหมดอายุ และ sub โดยใช้ endpoint JWKS ที่กำหนดค่า และตรวจสอบว่า token ถูกออกให้กับ HARNESS_MCP_OAUTH_CLIENT_ID ผ่าน claim azp HARNESS_MCP_OAUTH_RESOURCE คือตัวระบุทรัพยากรที่ได้รับการป้องกัน RFC 9728 ที่ใช้สำหรับการค้นพบและ challenges access tokens HarnessID ปัจจุบันใช้ aud: account แทน URL MCP ดังนั้นทรัพยากรจึงไม่ถูกเปรียบเทียบกับ aud

Account ID มาจาก claim HARNESS_MCP_OAUTH_ACCOUNT_CLAIM ของ token (ค่าเริ่มต้น account_id) ซึ่ง scope organization ของ HarnessID เติมข้อมูล แต่ละ session เก็บ access token ของผู้เรียกและส่งต่อไปยัง Harness API เป็น Authorization: Bearer ดังนั้น RBAC ของ Harness และบันทึกการตรวจสอบจะสะท้อนผู้ใช้ที่เข้าสู่ระบบแทนที่จะเป็น PAT ที่ใช้ร่วมกัน session ถูกผูกกับ sub และบัญชีที่สร้างด้วย: คำขอในภายหลังอาจมี token ที่รีเฟรชแล้ว แต่ token สำหรับผู้ใช้หรือบัญชีอื่นจะถูกปฏิเสธ

โดยปกติไคลเอ็นต์ต้องการเพียง URL ทรัพยากร MCP:

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

ไคลเอ็นต์อ่านเมตาดาต้าทรัพยากรที่ได้รับการป้องกัน ค้นพบ HARNESS_MCP_OAUTH_ISSUER จากนั้นใช้เมตาดาต้า RFC 8414 ของ authorization server นั้น หากไคลเอ็นต์ไม่รองรับการลงทะเบียนไคลเอ็นต์แบบไดนามิก ให้ใช้ ID ไคลเอ็นต์ mcp-client ที่ลงทะเบียนไว้ล่วงหน้า

ดู HarnessID OAuth สำหรับเซิร์ฟเวอร์ MCP ที่โฮสต์เอง สำหรับรายการตรวจสอบ QA Keycloak และคำสั่งการตรวจสอบความถูกต้อง

โหมดหลายผู้ใช้

ตั้งค่า HARNESS_MCP_MODE=multi-user สำหรับการ deploy HTTP แบบ shared ที่ไคลเอ็นต์แต่ละรายตรวจสอบสิทธิ์เป็นผู้ใช้ Harness ที่แตกต่างกัน ในโหมดนี้:

• HARNESS_API_KEY ต้อง ไม่ ถูกตั้งค่าในการกำหนดค่าเซิร์ฟเวอร์ — เซิร์ฟเวอร์ไม่เก็บข้อมูลประจำตัว Harness
• แต่ละ session ต้องให้ x-harness-api-key บนคำขอ initialize x-harness-account-id จำเป็นเฉพาะเมื่อ API key ไม่มี segment บัญชีฝังอยู่
• session อาจให้ header x-harness-org และ x-harness-project เพื่อตั้งค่า scope เริ่มต้นสำหรับ session นั้น
• Harness API key ไหลผ่านไปยังทุกการเรียก Harness API สำหรับ session นั้น ดังนั้นเส้นทางการตรวจสอบใน Harness สะท้อนผู้ใช้จริง
• HARNESS_MCP_AUTH_TOKEN เป็นอิสระและยังสามารถใช้เป็นเกตชั้น 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 ควบคุมการตรวจสอบความถูกต้องของ Host-header สำหรับการป้องกัน DNS-rebinding และ CORS จำกัดต้นทางของเบราว์เซอร์ ทั้งสองอย่างไม่ใช่การตรวจสอบสิทธิ์ ใช้ HARNESS_MCP_AUTH_TOKEN หรือเกตเวย์/reverse proxy ที่ตรวจสอบสิทธิ์สำหรับการควบคุมการเข้าถึง

การกำหนดค่าไคลเอ็นต์

หมายเหตุ: HARNESS_ORG และ HARNESS_PROJECT เป็นตัวเลือก ใช้ตั้งค่า org ID และ project ID เมื่อไม่ได้ระบุต่อการเรียกเครื่องมือ เอเจนต์สามารถค้นพบ orgs และ projects แบบไดนามิกโดยใช้ harness_list(resource_type="organization") และ harness_list(resource_type="project") ชื่อที่เลิกใช้แล้ว HARNESS_DEFAULT_ORG_ID และ HARNESS_DEFAULT_PROJECT_ID ยังคงยอมรับเพื่อความเข้ากันได้ย้อนหลัง

Hosted Harness MCP

Harness ยังรองรับ endpoint MCP ที่โฮสต์สำหรับบัญชีที่เปิดใช้งานบริการจัดการแล้ว สิ่งนี้มีประโยชน์เมื่อคุณต้องการ endpoint MCP ระยะไกลที่ใช้ร่วมกันแทนการรัน npx harness-mcp-v2 หรือโฮสต์ HTTP transport ด้วยตัวเอง

สำคัญ: การรับรองความถูกต้องของ MCP ที่โฮสต์ไว้ใช้ Harness Platform OAuth ซึ่ง ไม่ใช้ HARNESS_API_KEY ในการกำหนดค่าของไคลเอนต์ ความพร้อมใช้งานของ MCP ที่โฮสต์ไว้ถูกกำหนดค่าตามบัญชี Harness แต่ละบัญชี ดังนั้นคุณจะต้องทำงานร่วมกับ ฝ่ายสนับสนุน Harness เพื่อเปิดใช้งาน/กำหนดค่าการตั้งค่านี้ก่อนใช้งาน

ปลายทางที่โฮสต์ไว้ https://mcp.harness.io/mcp เป็นบริการที่มีการจัดการ การกำหนดค่า MCP ฝั่งไคลเอนต์ใน Claude, Cursor หรือ Cowork ไม่สามารถแทนที่ได้ว่าปลายทางจะกำหนดเส้นทางไปยังสภาพแวดล้อม Harness ใด สำหรับ Harness0 หรือสภาพแวดล้อม Harness SaaS ส่วนตัวอื่น ๆ โปรดขอให้ฝ่ายสนับสนุน Harness เปิดใช้งาน/กำหนดค่า MCP ที่โฮสต์ไว้สำหรับสภาพแวดล้อมนั้น หรือรันเซิร์ฟเวอร์ในเครื่อง/โฮสต์เองและตั้งค่า HARNESS_BASE_URL ไปยังโฮสต์ Harness เป้าหมาย

ตัวอย่าง MCP ที่โฮสต์ไว้:

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

ตัวอย่างที่มีทั้งรายการที่โฮสต์ไว้และในเครื่อง:

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

การแก้ไขปัญหา npx ENOENT หรือ node: No such file or directory

นี่คือความล้มเหลวในการเปิดกระบวนการของไคลเอนต์ ไม่ใช่ความล้มเหลวในการรับรองความถูกต้องของ Harness เซิร์ฟเวอร์ MCP ยังไม่ได้เริ่มทำงาน ดังนั้นการเปลี่ยน HARNESS_API_KEY จะไม่ส่งผลต่อ spawn npx ENOENT

แอป GUI (Cursor, Claude Desktop, Devin Desktop, VS Code) ไม่ได้สืบทอด PATH ของเชลล์ของคุณเสมอไป ดังนั้นจึงอาจไม่พบ npx หรือ node หลังจากการโหลดการกำหนดค่าใหม่ แก้ไขโดยใช้เส้นทางแบบสัมบูรณ์และตั้งค่า PATH อย่างชัดเจนในบล็อก 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"
      }
    }
  }
}

ค้นหาเส้นทางของคุณด้วย which npx และ which node ในเทอร์มินัล จากนั้นตรวจสอบให้แน่ใจว่าไดเรกทอรีที่มี node รวมอยู่ในค่า PATH ด้านบน ตำแหน่งทั่วไป:

• Homebrew (macOS): /opt/homebrew/bin/npx
• nvm: ~/.nvm/versions/node/v20.x.x/bin/npx (รัน nvm which current เพื่อค้นหาเส้นทางที่แน่นอน)
• System Node: /usr/local/bin/npx

Claude Desktop (claude_desktop_config.json)

npx (ติดตั้งเป็นศูนย์)

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

node (ติดตั้งในเครื่อง)

npm install -g harness-mcp-v2

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

Claude Code (ผ่าน claude mcp add)

npx (ติดตั้งเป็นศูนย์)

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

node (ติดตั้งในเครื่อง)

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

จากนั้นตั้งค่า HARNESS_API_KEY ในสภาพแวดล้อมของคุณหรือไฟล์ .env

Cursor (.cursor/mcp.json)

npx (ติดตั้งเป็นศูนย์ แนะนำสำหรับการกำหนดค่า Cursor ในเครื่อง)

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

รัน which npx ในเทอร์มินัลและใช้เส้นทางเต็มนั้นสำหรับ command; รวมไดเรกทอรีจาก which node ที่ด้านหน้าของ PATH

node (ติดตั้งในเครื่อง)

npm install -g harness-mcp-v2

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

รัน which harness-mcp-v2 หลังจาก npm install -g harness-mcp-v2 และใช้เส้นทางเต็มนั้นสำหรับ command; รวมไดเรกทอรีจาก which node ที่ด้านหน้าของ PATH

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

npx (ติดตั้งเป็นศูนย์)

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

node (ติดตั้งในเครื่อง)

npm install -g harness-mcp-v2

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

ใช้บิลด์ในเครื่องจากซอร์สหรือไม่?

แทนที่คำสั่งด้วยเส้นทางไปยัง index.js ที่สร้างไว้ของคุณ:

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

MCP Gateway

เซิร์ฟเวอร์ Harness MCP เข้ากันได้อย่างเต็มที่กับ MCP Gateways — พร็อกซีย้อนกลับที่ให้การรับรองความถูกต้องแบบรวมศูนย์ การกำกับดูแล การกำหนดเส้นทางเครื่องมือ และการสังเกตการณ์ข้ามเซิร์ฟเวอร์ MCP หลายตัว เนื่องจากเซิร์ฟเวอร์ใช้โปรโตคอล MCP มาตรฐานพร้อมทั้งการขนส่ง stdio และ HTTP จึงทำงานได้เบื้องหลังเกตเวย์ที่เข้ากันได้กับ MCP โดยไม่ต้องเปลี่ยนแปลงโค้ด

ทำไมต้องใช้เกตเวย์?

• การจัดการข้อมูลประจำตัวแบบรวมศูนย์ — ไม่มีคีย์ API ในการกำหนดค่าเอเจนต์
• การกำกับดูแลและการบันทึกการตรวจสอบสำหรับการเรียกเครื่องมือทั้งหมดข้ามทีม
• ปลายทางเดียวสำหรับเอเจนต์แทนการเชื่อมต่อ N ไปยังเซิร์ฟเวอร์ MCP N ตัว
• การควบคุมการเข้าถึง — จำกัดว่าทีมใดสามารถใช้เครื่องมือใดได้

Docker MCP Gateway

ลงทะเบียนเซิร์ฟเวอร์ในการกำหนดค่า Docker MCP Gateway ของคุณ:

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

Portkey

เพิ่มเซิร์ฟเวอร์ Harness MCP ไปยัง Portkey MCP Gateway ของคุณสำหรับการกำกับดูแลองค์กร การติดตามต้นทุน และการกำหนดเส้นทางหลาย LLM:

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

LiteLLM

เพิ่มไปยัง การกำหนดค่าพร็อกซี LiteLLM ของคุณ:

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

Envoy AI Gateway

เซิร์ฟเวอร์ทำงานร่วมกับ การสนับสนุน MCP ของ Envoy AI Gateway ผ่านการขนส่ง HTTP:

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

จากนั้นกำหนดค่า Envoy เพื่อกำหนดเส้นทางไปยัง http://localhost:8080/mcp เป็นแบ็กเอนด์ MCP ต้นทาง

Kong

ใช้ ปลั๊กอิน AI MCP Proxy ของ Kong เพื่อเปิดเผยเซิร์ฟเวอร์ Harness MCP ผ่านโครงสร้างพื้นฐานเกตเวย์ Kong ที่มีอยู่ของคุณ

เกตเวย์อื่น ๆ

เกตเวย์ใด ๆ ที่รองรับข้อกำหนด MCP (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers ฯลฯ) สามารถพร็อกซีเซิร์ฟเวอร์นี้ได้ สำหรับเกตเวย์ที่ใช้ stdio ให้ใช้การขนส่งเริ่มต้น สำหรับเกตเวย์ที่ใช้ HTTP ให้เริ่มเซิร์ฟเวอร์ด้วยการขนส่ง http และชี้เกตเวย์ไปที่ปลายทาง /mcp

Docker

สร้างและรันเซิร์ฟเวอร์เป็นคอนเทนเนอร์ Docker:

# Build the image
pnpm docker:build

# Run with your .env file
pnpm docker:run

# Or run directly with env vars
docker run --rm -p 3000:3000 \
  -e HARNESS_API_KEY=pat.xxx.xxx.xxx \
  -e HARNESS_ACCOUNT_ID=your-account-id \
  harness-mcp-server

คอนเทนเนอร์ทำงานในโหมด HTTP บนพอร์ต 3000 โดยค่าเริ่มต้นพร้อมการตรวจสอบสุขภาพในตัว

Kubernetes

ปรับใช้กับคลัสเตอร์ Kubernetes โดยใช้ไฟล์ manifest ที่ให้ไว้:

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

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

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

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

การปรับใช้รัน 2 เรพลิกาพร้อมพร็อบความพร้อม/ความมีชีวิต ขีดจำกัดทรัพยากร และบริบทความปลอดภัยที่ไม่ใช่รูท Service เปิดเผยพอร์ต 80 ภายใน (กำหนดเป้าหมายพอร์ตคอนเทนเนอร์ 3000)

การกำหนดค่า

เซิร์ฟเวอร์โหลดตัวแปรสภาพแวดล้อมจากไฟล์ .env ในโฟลเดอร์รากของโปรเจกต์โดยอัตโนมัติหากมีอยู่ คัดลอก .env.example ไปยัง .env และกรอกค่าของคุณ ตัวแปรสภาพแวดล้อมสามารถตั้งค่าผ่านเชลล์หรือการกำหนดค่าไคลเอนต์ MCP ของคุณได้เช่นกัน

ตัวแปร	จำเป็น	ค่าเริ่มต้น	คำอธิบาย
HARNESS_MCP_MODE	ไม่	single-user	โหมดการปรับใช้: single-user (คีย์ API แบบใช้ร่วมกัน), multi-user (HTTP พร้อมคีย์ API ต่อเซสชัน) หรือ oauth (HTTP พร้อมการตรวจสอบ access token ของ HarnessID)
HARNESS_API_KEY	ใช่*	--	โทเค็นการเข้าถึงส่วนบุคคลของ Harness หรือโทเค็นบัญชีบริการ จำเป็นในโหมด single-user ต้องไม่ตั้งค่าในโหมด multi-user หรือ oauth ซึ่งแต่ละเซสชันจะนำข้อมูลประจำตัวของตัวเองมา
HARNESS_ACCOUNT_ID	ไม่	(จาก PAT/SAT)	ตัวระบุบัญชี Harness ถูกแยกออกจากโทเค็น PAT/SAT โดยอัตโนมัติในโหมดผู้ใช้คนเดียว เซสชันผู้ใช้หลายคนสามารถระบุของตนเองผ่าน x-harness-account-id เมื่อคีย์ API ไม่ได้ฝังตัวระบุไว้
HARNESS_BASE_URL	ไม่	https://app.harness.io (https://mcp.harness.io/cli ในโหมด OAuth)	URL พื้นฐานของ Harness API/UI โหมด OAuth จะกำหนดเส้นทางผ่านพร็อกซี MCP /cli ที่โฮสต์ไว้โดยค่าเริ่มต้น โหมดอื่นใช้ Harness SaaS API โดยตรง
HARNESS_MCP_OAUTH_ISSUER	ไม่	https://id.harness.io/idp/realms/HarnessIDP	ผู้ออก HarnessID ที่ตรวจสอบตรงกับค่า claim iss ของ access token
HARNESS_MCP_OAUTH_RESOURCE	ไม่	https://mcp.harness.io/mcp	URL MCP มาตรฐานสาธารณะที่เผยแพร่เป็นตัวระบุทรัพยากร RFC 9728
HARNESS_MCP_OAUTH_JWKS_URI	ไม่	<issuer>/protocol/openid-connect/certs	จุดสิ้นสุด JWKS ของ HarnessID ที่ใช้ตรวจสอบลายเซ็น access token แบบ RS256
HARNESS_MCP_OAUTH_CLIENT_ID	ไม่	mcp-client	ไคลเอนต์ HarnessID ที่ต้องออก access token ให้ ตรวจสอบกับค่า claim azp ของโทเค็น
HARNESS_MCP_OAUTH_ACCOUNT_CLAIM	ไม่	account_id	ค่า claim ของ access token ที่เก็บ ID บัญชี Harness ซึ่งเติมโดยขอบเขต organization ของ HarnessID
HARNESS_MCP_OAUTH_SCOPES	ไม่	openid profile email organization	ขอบเขตที่คั่นด้วยช่องว่างซึ่งประกาศในเมตาดาต้าทรัพยากรที่ได้รับการป้องกัน RFC 9728
HARNESS_FME_API_KEY	ไม่	--	ข้อมูลประจำตัว FME/Split Admin แบบผู้ใช้คนเดียว/โฮสต์เองสำหรับทรัพยากร fme_ ใน โหมดเดิม (workspace_id) เท่านั้น FME เดิมไม่พร้อมใช้งานในโหมด OAuth ดังนั้นโทเค็น HarnessID จะไม่ถูกส่งไปยัง api.split.io; ให้ใช้ขอบเขต org_id+project_id ดั้งเดิมของ Harness แทน ต้องไม่ตั้งค่าในโหมด multi-user หรือ oauth
HARNESS_FME_BASE_URL	ไม่	https://api.split.io	URL พื้นฐาน Split/FME Admin API ที่ใช้โดยทรัพยากร fme_ ใน โหมดเดิม (workspace_id) เท่านั้น URL HTTP ต้องใช้ HARNESS_ALLOW_HTTP=true สำหรับการพัฒนาท้องถิ่น โหมดดั้งเดิมของ Harness (org_id+project_id) จะไม่สนใจค่านี้และใช้ HARNESS_API_KEY/HARNESS_BASE_URL มาตรฐานแทน
HARNESS_ORG	ไม่	--	ID องค์กร ใช้เมื่อไม่ได้ระบุ org_id ต่อการเรียกเครื่องมือ หากละเว้น ต้องระบุ org_id อย่างชัดเจน เอเจนต์ยังสามารถค้นพบองค์กรแบบไดนามิกผ่าน harness_list(resource_type="organization")
HARNESS_PROJECT	ไม่	--	ID โปรเจกต์ ใช้เมื่อไม่ได้ระบุ project_id ต่อการเรียกเครื่องมือ เอเจนต์ยังสามารถค้นพบโปรเจกต์แบบไดนามิกผ่าน harness_list(resource_type="project")
HARNESS_API_TIMEOUT_MS	ไม่	30000	หมดเวลาคำขอ HTTP ในหน่วยมิลลิวินาที
HARNESS_MAX_RETRIES	ไม่	3	จำนวนครั้งในการลองใหม่สำหรับความล้มเหลวชั่วคราว (429, 5xx)
HARNESS_MAX_BODY_SIZE_MB	ไม่	10	ขนาดสูงสุดของเนื้อหาคำขอ HTTP ในหน่วย MB สำหรับการขนส่ง http
HARNESS_RATE_LIMIT_RPS	ไม่	10	การจำกัดคำขอฝั่งไคลเอนต์ (คำขอต่อวินาที) ไปยัง Harness APIs
LOG_LEVEL	ไม่	info	ระดับความละเอียดของบันทึก: debug, info, warn, error
HARNESS_TOOLSETS	ไม่	(ค่าเริ่มต้น)	รายการชุดเครื่องมือที่คั่นด้วยเครื่องหมายจุลภาค ค่าว่างจะโหลดชุดเครื่องมือเริ่มต้น รองรับ +name เพื่อรวมชุดเครื่องมือที่เลือกใช้อย่างชัดเจน และ -name เพื่อลบค่าเริ่มต้น (ดู การกรองชุดเครื่องมือ)
HARNESS_READ_ONLY	ไม่	false	บล็อกการดำเนินการที่เปลี่ยนแปลงทั้งหมด (สร้าง, อัปเดต, ลบ, ดำเนินการ) อนุญาตเฉพาะรายการและดึงข้อมูลเท่านั้น มีประโยชน์สำหรับสภาพแวดล้อมที่ใช้ร่วมกัน/สาธิต
HARNESS_AUTO_APPROVE_RISK	ไม่	none	เกณฑ์การอนุมัติอัตโนมัติตามความเสี่ยงสำหรับเวิร์กโฟลว์อัตโนมัติ การดำเนินการที่มีความเสี่ยงเท่ากับหรือต่ำกว่าเกณฑ์นี้จะดำเนินการโดยไม่ต้องยืนยัน ค่า: none, low_write, medium_write, high_write, all. ดู การสอบถาม
HARNESS_SKIP_ELICITATION	ไม่	false	เลิกใช้แล้ว — ใช้ HARNESS_AUTO_APPROVE_RISK=all แทน เก็บไว้เพื่อความเข้ากันได้ย้อนหลัง
HARNESS_ALLOW_HTTP	ไม่	false	อนุญาต HARNESS_BASE_URL ที่ไม่ใช่ HTTPS โดยค่าเริ่มต้น เซิร์ฟเวอร์บังคับใช้ HTTPS เพื่อความปลอดภัย ตั้งค่าเป็น true เฉพาะสำหรับการพัฒนาท้องถิ่นกับอินสแตนซ์ Harness ที่ไม่มี TLS
HARNESS_PIPELINE_VERSION	ไม่	0	(อัลฟา) เวอร์ชัน YAML ของไปป์ไลน์ 0 โหลดประเภททรัพยากร pipeline และไม่รวม pipeline_v1; 1 โหลด pipeline_v1 และไม่รวม pipeline เซสชัน HTTP สามารถแทนที่ค่านี้ได้ในเวลาการเริ่มต้นด้วย x-harness-pipeline-version: 0 หรือ 1
HARNESS_MCP_ALLOWED_HOSTS	ไม่	--	รายชื่อโฮสต์ที่คั่นด้วยเครื่องหมายจุลภาคซึ่งอนุญาตโดยการตรวจสอบส่วนหัว Host ของการขนส่ง HTTP mcp.harness.io อนุญาตโดยค่าเริ่มต้นสำหรับการผูก localhost; เพิ่มพร็อกซี/โดเมนที่กำหนดเองที่นี่
HARNESS_MCP_AUTH_TOKEN	ไม่	--	โทเค็น Bearer แบบคงที่ที่จำเป็นบนเส้นทาง HTTP /mcp เมื่อตั้งค่า จำเป็นโดยค่าเริ่มต้นสำหรับการผูกผู้ใช้คนเดียวและผู้ใช้หลายคนที่ไม่ใช่ loopback ต้องไม่ตั้งค่าในโหมด oauth
HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP	ไม่	false	อนุญาตการขนส่ง HTTP ที่ไม่มีการตรวจสอบสิทธิ์บนการผูกที่ไม่ใช่ loopback อย่างชัดเจน ใช้เฉพาะหลังการควบคุมที่ตรวจสอบสิทธิ์อื่น
HARNESS_MCP_TRUST_PROXY	ไม่	0	จำนวนฮอปพร็อกซีรีเวิร์ส/โหลดบาลานเซอร์ที่เชื่อถือสำหรับการแก้ไข IP ไคลเอนต์ (Express trust proxy) ตั้งค่าเป็นจำนวนพร็อกซีที่อยู่หน้าเซิร์ฟเวอร์เพื่อให้การจำกัดอัตราต่อ IP ใช้คีย์กับไคลเอนต์จริงแทนพีียร์ซ็อกเก็ตพร็อกซี
HARNESS_MCP_LOG_FILE	ไม่	~/.claude/harness-mcp.log	ไฟล์ที่ใช้สำหรับการวินิจฉัยการตัดการเชื่อมต่อ/ขัดข้องของ stdio เมื่อ stderr อาจไม่พร้อมใช้งานอีกต่อไป
HARNESS_LOG_UNSAFE_BODIES	ไม่	false	รวมเนื้อหาคำขอ/การตอบสนองดิบในบันทึก ปิดโดยค่าเริ่มต้นเนื่องจากเนื้อหาสามารถมีความลับ; เปิดใช้งานเฉพาะสำหรับการดีบักท้องถิ่น
HARNESS_AUDIT_FILE	ไม่	--	ผนวกเหตุการณ์การตรวจสอบไปยังไฟล์ JSON ที่คั่นด้วยบรรทัดใหม่สำหรับการรวบรวมท้องถิ่นที่ทนทาน
HARNESS_AUDIT_WEBHOOK_URL	ไม่	--	จุดสิ้นสุด HTTPS ที่รับเหตุการณ์การตรวจสอบแบบแบตช์ URL HTTP ต้องใช้ HARNESS_ALLOW_HTTP=true สำหรับการพัฒนาท้องถิ่น
HARNESS_AUDIT_WEBHOOK_TOKEN	ไม่	--	โทเค็น Bearer ทางเลือกที่ส่งไปยังเว็บฮุคการตรวจสอบ
HARNESS_AUDIT_WEBHOOK_BATCH_SIZE	ไม่	10	จำนวนเหตุการณ์การตรวจสอบที่จะรวมเป็นแบตช์ก่อนการส่งเว็บฮุค
HARNESS_AUDIT_WEBHOOK_FLUSH_MS	ไม่	5000	เวลาสูงสุดในการเก็บเหตุการณ์ตรวจสอบก่อนการส่งผ่านเว็บฮุค
OTEL_EXPORTER_OTLP_ENDPOINT	ไม่	--	เปิดใช้งานสแปนการตรวจสอบ OpenTelemetry เมื่อติดตั้งแพ็กเกจ OpenTelemetry ที่เป็นตัวเลือก
HARNESS_SEARCH_PROVIDER	ไม่	local	แบ็กเอนด์การค้นหาเชิงความหมาย: local (การฝัง ONNX ในกระบวนการ ค่าเริ่มต้น), remote (บริการค้นหาภายนอกผ่าน HTTP จำเป็นสำหรับโหมดผู้ใช้หลายคน) หรือ none (ปิดการค้นหาเชิงความหมาย ใช้การกระจายคำหลักแบบ scatter-gather เท่านั้น) ใช้ none ในสภาพแวดล้อมที่ตัดการเชื่อมต่ออินเทอร์เน็ตหรือเมื่อไม่ต้องการโหลดโมเดลตอนเริ่มต้น
HARNESS_SEARCH_SERVICE_URL	ไม่	--	URL ฐานของบริการค้นหาระยะไกลเมื่อ HARNESS_SEARCH_PROVIDER=remote (เช่น http://search-svc:8080) จำเป็นเมื่อใช้ผู้ให้บริการ remote
HARNESS_SEARCH_SERVICE_HEADERS	ไม่	--	ออบเจกต์ JSON ของส่วนหัวที่ส่งพร้อมกับทุกคำขอไปยังบริการค้นหาระยะไกล รองรับรูปแบบการรับรองความถูกต้องใดๆ: {"Authorization":"Bearer tok"}, {"x-api-key":"key"} หรือส่วนหัวภายในระหว่างบริการหลายรายการ
HARNESS_HF_CACHE_DIR	ไม่	/tmp/hf-cache	ไดเรกทอรีสำหรับแคชโมเดล @huggingface/transformers ที่ใช้โดยผู้ให้บริการค้นหา local อิมเมจ Docker เตรียมโมเดลไว้ล่วงหน้าใน /app/.cache/hf เพื่อหลีกเลี่ยงการดาวน์โหลดระหว่างรันไทม์ ตั้งค่าเป็นเส้นทางวอลุ่มถาวรในการปรับใช้การผลิต
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	ไม่	3	จำนวนสูงสุดของการดาวน์โหลดบล็อกบันทึกพร้อมกันที่ออกโดย harness_diagnose เมื่อดึงบันทึกสำหรับขั้นตอนที่ล้มเหลว เพิ่มเฉพาะเมื่อเวลาในการวินิจฉัยถูกครอบงำโดยเวลารอการดึงบันทึกและพอดมีหน่วยความจำเหลือเพียงพอ

Semantic Search

harness_search ใช้ semantic routing เพื่อจำกัดขอบเขตการเรียก scatter-gather API ก่อนที่จะกระจายไปยัง Harness มีผู้ให้บริการค้นหาสามรายการให้เลือก:

ผู้ให้บริการ	เมื่อใดควรใช้
local (ค่าเริ่มต้น)	โหมด stdio ผู้ใช้คนเดียว รัน all-MiniLM-L6-v2 ในกระบวนการผ่าน @huggingface/transformers ดาวน์โหลดโมเดล ~23 MB ในการใช้งานครั้งแรก การเริ่มครั้งถัดไปจะใช้แคช
remote	โหมด HTTP ผู้ใช้หลายคน (โฮสต์โดย Harness) มอบหมายการฝังและการดึงข้อมูลให้กับบริการค้นหาภายนอก การแยกผู้เช่าได้รับการบังคับใช้ผ่าน tenant_id — ความรู้/เอกสารแบบคงที่ใช้ global ข้อมูลเอนทิตีตามบัญชีใช้ ID บัญชี
none	ปิดใช้งาน semantic search ทั้งหมด กลับไปใช้ keyword scatter-gather ในทุกประเภททรัพยากร

การกำหนดค่าผู้ให้บริการระยะไกล:

HARNESS_SEARCH_PROVIDER=remote
HARNESS_SEARCH_SERVICE_URL=http://search-svc:8080

# Auth — any scheme via HARNESS_SEARCH_SERVICE_HEADERS (JSON object):
HARNESS_SEARCH_SERVICE_HEADERS='{"Authorization":"Bearer <token>"}'   # standard bearer
HARNESS_SEARCH_SERVICE_HEADERS='{"x-api-key":"<key>"}'               # API key header
HARNESS_SEARCH_SERVICE_HEADERS='{"x-harness-token":"<svc-token>"}'   # internal service-to-service
# Multiple headers (e.g. service mesh + tenant routing):
HARNESS_SEARCH_SERVICE_HEADERS='{"x-harness-token":"<tok>","x-tenant":"<id>"}'
# No auth (service mesh / mTLS handles it):
# omit HARNESS_SEARCH_SERVICE_HEADERS entirely

การทดสอบผู้ให้บริการระยะไกลในเครื่อง ด้วยบริการ stub ที่รวมมา (ไม่มีการพึ่งพาภายนอก):

# 1. Create a venv and install FastAPI
python3 -m venv .venv-stub
.venv-stub/bin/pip install fastapi uvicorn

# 2. Start the stub (in-memory, cosine similarity, corpus + tenant filtering)
.venv-stub/bin/uvicorn stub-search-service:app --port 8082

# 3. Build the MCP server
pnpm build

# 4. Run the integration smoke test
node test-remote-provider.mjs
# Expected output:
#   available: true
#   indexed 2 docs
#   entity search results: pipeline:ts-test score=... corpus=entities
#   knowledge search results: schema:trigger score=...
#   all-corpus search results: (merged, sorted by score)
#   isolation check (other-acct, should be empty): PASS

# 5. Tear down
kill $(lsof -ti :8082)

stub (stub-search-service.py) ใช้สัญญา /v1/health, /v1/ingest และ /v1/search เดียวกันกับบริการค้นหาการผลิต ใช้การฝังแบบ bag-of-chars อย่างง่าย ดังนั้นไม่ต้องดาวน์โหลดโมเดล — ผลลัพธ์มีความเป็นไปได้ทางความหมายแต่ไม่ใช่คุณภาพการผลิต

การบังคับใช้ HTTPS

HARNESS_BASE_URL ต้องใช้ HTTPS โดยค่าเริ่มต้น หากคุณตั้งค่า URL ที่ไม่ใช่ HTTPS (เช่น http://localhost:8080) เซิร์ฟเวอร์จะปฏิเสธการเริ่มต้นด้วย:

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

การบันทึกการตรวจสอบ

การดำเนินการ Harness API ทั้งหมดที่ส่งผ่าน registry (list, get, create, update, delete และ execute) จะสร้างเหตุการณ์การตรวจสอบแบบมีโครงสร้างเมื่อมีการกำหนดค่า audit sinks เหตุการณ์ที่เปลี่ยนแปลงรวมถึงเส้นทางการยืนยันที่ใช้โดย elicitation หรือการอนุมัติอัตโนมัติเมื่อมีบริบทการยืนยัน เหตุการณ์การอ่านในปัจจุบันละเว้นข้อมูลเมตาการยืนยัน เครื่องมือการค้นพบข้อมูลเมตาและ schema ในเครื่องที่ข้าม registry เช่น harness_describe และ harness_schema ไม่เป็นส่วนหนึ่งของสตรีมการตรวจสอบนี้ stderr sink ลงทะเบียนโดยค่าเริ่มต้นแต่ผ่าน logger ปกติและปฏิบัติตาม LOG_LEVEL กำหนดค่า file หรือ webhook sinks สำหรับการรวบรวมการตรวจสอบที่คงทน:

• HARNESS_AUDIT_FILE ผนวกเหตุการณ์ JSON ที่คั่นด้วยบรรทัดใหม่สำหรับการรวบรวมในเครื่อง
• HARNESS_AUDIT_WEBHOOK_URL โพสต์ชุด { "events": [...] } ไปยัง HTTPS webhook โดยเลือกได้ด้วย HARNESS_AUDIT_WEBHOOK_TOKEN ชุดที่ล้มเหลวจะถูกจัดคิวใหม่ด้วยความจุที่จำกัดและสุดท้ายจะถูกทิ้งพร้อมคำเตือนแทนที่จะบล็อกการทำงานของเครื่องมือ
• OTEL_EXPORTER_OTLP_ENDPOINT เปิดใช้งาน audit spans เมื่อติดตั้ง OpenTelemetry peer dependencies ที่เป็นตัวเลือก sink ใช้ tracer provider ที่มีอยู่เมื่อลงทะเบียนแล้ว มิฉะนั้นจะบูตสแตรปตัวส่งออก OTLP แบบสแตนด์อโลน

แต่ละเหตุการณ์รวมถึงชื่อเครื่องมือ ประเภททรัพยากร การดำเนินการ ตัวระบุ เวลาประทับ ความเสี่ยง ผลลัพธ์ วิธี/เส้นทาง HTTP ระยะเวลา และวิธีการยืนยันเมื่อเกี่ยวข้อง Audit sinks เป็น telemetry แบบ best-effort ปัญหาการจัดส่งจะถูกบันทึกและไม่เล่นซ้ำหรือเปลี่ยนแปลงการดำเนินการ Harness API พื้นฐาน สำหรับรายละเอียดการตั้งค่า OTel และแอตทริบิวต์ span ดู specs/005-otel-audit-sink.md

ข้อมูลอ้างอิงเครื่องมือ

เซิร์ฟเวอร์เปิดเผยเครื่องมือ MCP 11 รายการ เครื่องมือ API ส่วนใหญ่ยอมรับ org_id และ project_id เป็นการแทนที่แบบเลือกได้ — หากละเว้น จะย้อนกลับไปใช้ HARNESS_ORG และ HARNESS_PROJECT harness_describe เป็นข้อมูลเมตาในเครื่องเท่านั้นและไม่ใช้ขอบเขต org/project

การสนับสนุน URL: เครื่องมือที่เผชิญกับ API ส่วนใหญ่ยอมรับพารามิเตอร์ url — วาง URL UI ของ Harness และเซิร์ฟเวอร์จะแยก org, project, ประเภททรัพยากร, ID ทรัพยากร, ID pipeline และ ID การดำเนินการโดยอัตโนมัติ harness_describe ไม่ยอมรับ url

การสนับสนุนขอบเขต: ประเภททรัพยากรที่มีตัวแปร account/org/project เปิดเผย supportedScopes ใน harness_describe ส่ง resource_scope เมื่อคุณต้องการระดับเฉพาะ:

• resource_scope: "account" ส่งเฉพาะ accountIdentifier
• resource_scope: "org" ส่ง accountIdentifier และ orgIdentifier
• resource_scope: "project" ส่งตัวระบุ account, org และ project

ทรัพยากรหลายขอบเขตปัจจุบันรวมถึง connector, service, environment, infrastructure, secret, file_store, template, policy และ policy_set หากละเว้น resource_scope registry จะใช้ขอบเขตเริ่มต้นของทรัพยากรและค่าเริ่มต้นที่กำหนดค่าไว้ ยกเว้นทรัพยากรที่ทำเครื่องหมายเป็นขอบเขตเลือกได้อาจละเว้น org/project เว้นแต่จะส่งอย่างชัดเจน URL ของ Harness ยังสามารถตั้งค่าขอบเขตโดยอัตโนมัติเมื่อเส้นทางมีบริบทระดับบัญชีหรือระดับโครงการ

ผลลัพธ์แบบมีโครงสร้าง: ทุกเครื่องมือประกาศ MCP outputSchema harness_list ปรับการตอบสนอง Harness ที่คล้ายรายการให้เป็นเนื้อหาแบบมีโครงสร้างรูปวัตถุเพื่อให้ไคลเอนต์ที่เข้มงวดสามารถตรวจสอบได้: อาร์เรย์ระดับบนสุดกลายเป็น { "items": [...], "total": <count>, "page": <page> } และคีย์ wrapper ทั่วไปเช่น content, data, body, objects หรือ features จะถูกยกไปที่ items เมื่อจำเป็น การตอบสนองข้อความยังคงมีเพย์โหลด JSON แบบกระชับที่ส่งกลับไปยังไคลเอนต์ทั้งหมด

เครื่องมือ	คำอธิบาย
harness_describe	ค้นพบประเภททรัพยากร การดำเนินการ และฟิลด์ที่มีอยู่ ไม่มีการเรียก API — ส่งคืนข้อมูลเมตาของรีจิสทรีในเครื่อง
harness_schema	ดึงคำจำกัดความและตัวอย่าง YAML/JSON Schema ที่แน่นอนสำหรับการสร้าง/อัปเดตทรัพยากร สคีมาของไปป์ไลน์/เทมเพลตถูกจัดรวมไว้; สคีมาของคอนเนกเตอร์ สภาพแวดล้อม บริการ ความลับ และโครงสร้างพื้นฐานเป็นสคีมาของเอนทิตีที่คำนึงถึงขอบเขต ซึ่งดึงมาจากสแนปช็อตที่จัดรวมไว้หรือ NG /yaml-schema; สคีมา release_process และ release_activity ถูกดึงแบบสดจาก RMG /api/yamlSchema รองรับการเจาะลึกผ่าน path
harness_list	แสดงรายการทรัพยากรของประเภทที่กำหนด พร้อมการกรอง การค้นหา และการแบ่งหน้า
harness_get	รับทรัพยากรเดี่ยวตามตัวระบุ
harness_create	สร้างทรัพยากรใหม่ รองรับไปป์ไลน์แบบอินไลน์และแบบรีโมต (ที่ใช้ Git) แจ้งให้ผู้ใช้ยืนยันผ่าน elicitation
harness_update	อัปเดตทรัพยากรที่มีอยู่ รองรับไปป์ไลน์แบบอินไลน์และแบบรีโมต (ที่ใช้ Git) แจ้งให้ผู้ใช้ยืนยันผ่าน elicitation
harness_delete	ลบทรัพยากร แจ้งให้ผู้ใช้ยืนยันผ่าน elicitation เป็นการทำลายล้าง
harness_execute	ดำเนินการกับทรัพยากร (รัน/รันไปป์ไลน์ซ้ำ นำเข้าไปป์ไลน์จาก Git สลับแฟล็ก ซิงค์แอป) แจ้งให้ผู้ใช้ยืนยันผ่าน elicitation สำหรับการรันไปป์ไลน์ ให้ใช้เวิร์กโฟลว์อินพุตรันไทม์ด้านล่าง (รองรับการขยายชวเลข branch/tag/pr_number/commit_sha)
harness_search	ค้นหาข้ามประเภททรัพยากรของ Harness ด้วยคำค้นหาเดียว ใช้การจัดเส้นทางเชิงความหมาย (local all-MiniLM-L6-v2 ONNX embeddings, 384-dim) เพื่อทำนายประเภททรัพยากรที่เกี่ยวข้องจากคลัง knowledge ที่จัดทำดัชนีเมื่อเริ่มต้น — โดยทั่วไปจะจำกัดจาก ~163 ประเภทเหลือ 1–8 ก่อน scatter-gather กลับไปใช้การค้นหาแบบคีย์เวิร์ดเต็มรูปแบบเมื่อความเชื่อมั่นเชิงความหมายต่ำ การตอบสนองรวมถึง semantic_routed และ types_skipped เมื่อการจัดเส้นทางทำงาน ดู docs/search-guidelines.md สำหรับวิธีทำให้ประเภททรัพยากรใหม่สามารถค้นพบได้
harness_diagnose	วินิจฉัยทรัพยากร pipeline, connector, delegate และ gitops_application (นามแฝง: execution -> pipeline, gitops_app -> gitops_application) สำหรับไปป์ไลน์ ส่งคืนระยะเวลาและรายละเอียดความล้มเหลวของสเตจ/สเต็ป; สำหรับคอนเนกเตอร์/ดีลิเกต/แอป GitOps ส่งคืนสัญญาณสุขภาพและการแก้ไขปัญหาที่ตรงเป้าหมาย
harness_status	รับแดชบอร์ดสุขภาพโครงการแบบเรียลไทม์ — การดำเนินการล่าสุด อัตราความล้มเหลว และลิงก์ลึก

เวิร์กโฟลว์การค้นหาสคีมา

ใช้ harness_schema ก่อนสร้างหรืออัปเดตทรัพยากรที่ใช้ YAML เพื่อให้เอเจนต์สามารถคัดลอกชื่อฟิลด์และข้อจำกัดที่แน่นอนแทนการเดาจากข้อความ

• สคีมาที่จัดรวมไว้รวมถึง pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1 และ agent-pipeline
• สคีมาของเอนทิตีรวมถึง connector, environment, service, secret และ infrastructure สคีมาเหล่านี้คำนึงถึงขอบเขต (account, org หรือ project) และต้องใช้ org_id/project_id เมื่อขอบเขตที่เลือกต้องการ
• คำจำกัดความการจัดการการเผยแพร่ (release_process, release_activity) ดึง JSON Schema แบบสดจาก RMG /api/yamlSchema (ไม่ได้จัดรวมไว้) ส่ง scope, org_id และ project_id เมื่อกำหนดขอบเขตเป็น org หรือ project
• สแนปช็อตเอนทิตีที่จัดเก็บไว้จะถูกใช้ก่อนเมื่อตรงกับบัญชีรันไทม์; มิฉะนั้นเครื่องมือจะกลับไปใช้ Harness NG /yaml-schema API และแคชผลลัพธ์
• ละเว้น path สำหรับสรุปฟิลด์/ส่วน จากนั้นส่ง path ที่คั่นด้วยจุดเพื่อตรวจสอบคำจำกัดความที่ซ้อนกัน

ตัวอย่าง:

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

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

ผู้ดูแลสามารถรีเฟรชสแนปช็อตเอนทิตีที่จัดเก็บไว้ด้วย pnpm sync-entity-schemas เมื่อสคีมา YAML ของเอนทิตี Harness เปลี่ยนแปลง

ตัวอย่างเครื่องมือ

ค้นพบทรัพยากรที่มีอยู่:

{ "resource_type": "pipeline" }

แสดงรายการองค์กรในบัญชี:

{ "resource_type": "organization" }

แสดงรายการโครงการในองค์กร:

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

แสดงรายการไปป์ไลน์ในโครงการ:

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

รับบริการเฉพาะ:

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

รันไปป์ไลน์:

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

สลับแฟล็กฟีเจอร์:

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

ค้นหาข้ามทุกประเภททรัพยากร:

{ "query": "payment-service" }

วินิจฉัยการดำเนินการตาม ID (โหมดสรุป — ค่าเริ่มต้น):

{ "execution_id": "abc123XYZ" }

วินิจฉัยจาก URL ของ Harness:

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

วินิจฉัยการเชื่อมต่อคอนเนกเตอร์:

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

วินิจฉัยสุขภาพดีลิเกต:

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

วินิจฉัยแอป GitOps (พร้อมตัวเลือก):

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

รับรายงานการดำเนินการล่าสุดสำหรับไปป์ไลน์:

{ "pipeline_id": "my-pipeline" }

โหมดวินิจฉัยเต็มรูปแบบพร้อม YAML และบันทึกสเต็ปที่ล้มเหลว:

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

โหมดสรุปพร้อมเปิดใช้บันทึก (ดีที่สุดของทั้งสองแบบ):

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

รับสถานะสุขภาพโครงการ:

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

แสดงรายการสคีมาฐานข้อมูลที่กรองตามประเภทการย้ายข้อมูล:

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

แสดงรายการอินสแตนซ์ฐานข้อมูลสำหรับสคีมา:

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

รับไปป์ไลน์การเขียน LLM ที่แก้ไขแล้วสำหรับสคีมาและอินสแตนซ์:

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

แสดงรายการชื่อออบเจกต์สแนปช็อต (เช่น ตาราง) สำหรับอินสแตนซ์สคีมา:

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

รับข้อมูลเมตาสแนปช็อตเต็มรูปแบบสำหรับออบเจกต์ที่มีชื่อเฉพาะ:

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

เวิร์กโฟลว์การรันไปป์ไลน์ (แนะนำ)

สำหรับไปป์ไลน์ v0 ให้ใช้ลำดับนี้เพื่อลดข้อผิดพลาดอินพุตขณะรันไทม์:

1. ค้นพบอินพุตรันไทม์ที่จำเป็น

• harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
• เทมเพลตที่ส่งคืนแสดงตัวยึดตำแหน่ง <+input> ที่ต้องระบุค่า

2. เลือกกลยุทธ์อินพุต

• ตัวแปรง่าย: ส่ง inputs แบบคีย์-ค่าแบบเรียบ (ตัวอย่างเช่น {"branch":"main","env":"prod"})

• อินพุตที่ซับซ้อน/เชิงโครงสร้าง: ใช้ input_set_ids (บล็อก CI codebase/build และอินพุตเทมเพลตที่ซ้อนกันจัดการได้ดีที่สุดด้วยวิธีนี้)

• คีย์ชวเลข CI codebase (เฉพาะการรันไปป์ไลน์):

  คีย์ชวเลข	โครงสร้างที่ขยาย
  branch	build.type=branch, build.spec.branch=<value>
  tag	build.type=tag, build.spec.tag=<value>
  pr_number	build.type=PR, build.spec.number=<value>
  commit_sha	build.type=commitSha, build.spec.commitSha=<value>

• ข้อจำกัด: การขยายชวเลขจะถูกข้ามเมื่อมี inputs.build อยู่แล้ว (build ที่ชัดเจนชนะ)

3. ดำเนินการรัน

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

• สำหรับไปป์ไลน์ที่ใช้ Git ซึ่งควรโหลด YAML จากสาขาที่ไม่ใช่ค่าเริ่มต้น ให้ส่ง params.pipeline_branch (ส่งไปยัง Harness เป็น branch) ตัวเลือกคำจำกัดความที่ชัดเจนนี้มีความสำคัญเหนือกว่านามแฝง params.branch inputs.branch เลือกสาขา CI codebase แยกต่างหาก:

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

4. ไม่บังคับ: รวมทั้งสองแบบ

• ใช้ input_set_ids สำหรับโครงสร้างพื้นฐานและ inputs สำหรับการแทนที่แบบง่าย

สำหรับไปป์ไลน์ v1:

1. ดึง harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>") สำหรับไปป์ไลน์ที่ใช้ Git ให้ส่ง branch_name, connector_ref และ repo_name ผ่าน params
2. ใช้แต่ละ inputs[].details.name ที่ส่งคืนเป็นคีย์ระดับบนสุดใน harness_execute.inputs
3. รัน harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}) เซิร์ฟเวอร์ห่อค่าเหล่านี้ภายใต้ราก YAML inputs: และส่งเนื้อหา inputs_yaml ของ API

หากฟิลด์ที่จำเป็นไม่ได้รับการแก้ไข เครื่องมือจะส่งคืนข้อผิดพลาด pre-flight พร้อมคีย์ที่คาดหวังและชุดอินพุตที่แนะนำ คุณสามารถตรวจสอบการแมปชวเลขที่มีอยู่ได้ด้วย harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands)

การดำเนินการไปป์ไลน์แบบไดนามิก

ใช้ pipeline_dynamic_execution.run เมื่อเอเจนต์หรือระบบภายนอกสร้าง YAML ของไปป์ไลน์ v0 ทั้งหมดในขณะรันไทม์และจำเป็นต้องรันกับ Harness pipeline shell ที่มีอยู่ นี่ไม่ใช่การแทนที่ pipeline.run ปกติ: ไปป์ไลน์ v0 ที่บันทึกไว้ต้องมีอยู่แล้ว ต้องเปิดใช้งาน Allow Dynamic Execution ทั้งในระดับบัญชีและระดับไปป์ไลน์ และผู้เรียกต้องมีสิทธิ์ Edit และ Execute บนไปป์ไลน์

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

ข้อจำกัด:

• body ต้องเป็นออบเจกต์ที่มีฟิลด์ yaml บอดี้สตริงดิบจะถูกปฏิเสธโดย schema harness_execute สาธารณะ
• body.yaml อาจเป็นสตริง YAML หรือออบเจกต์ JSON ของไปป์ไลน์ JSON จะถูกแปลงเป็น YAML ก่อนส่งคำขอ
• ตัวยึดตำแหน่ง <+input> ในขณะรันไทม์จะไม่ถูกแก้ไขโดย API นี้ ส่ง YAML ที่แก้ไขอย่างสมบูรณ์แล้ว
• ชุดอินพุต การเลือกดำเนินการบางสเตจ การลองใหม่ และทริกเกอร์ไม่ได้รับการสนับสนุนโดย endpoint การดำเนินการแบบไดนามิก
• การดำเนินการคือ high_write และใช้เส้นทางการยืนยัน/อนุมัติอัตโนมัติปกติ การตอบสนองจะฉาย envelope ของ API ไปยัง { "execution_id": "...", "status": "..." } และรวมลิงก์การดำเนินการ openInHarness เมื่อมีข้อมูลขอบเขต

หาก Harness ปฏิเสธการรันว่าไม่ได้เปิดใช้งาน ให้ตรวจสอบทั้งการตั้งค่า Allow Dynamic Execution ระดับบัญชีและการสลับระดับไปป์ไลน์ภายใต้ Pipeline -> Advanced Options -> Dynamic Execution Settings

การตรวจสอบอินพุตการดำเนินการ

ใช้ execution_inputs หลังการรันเพื่อตรวจสอบ YAML อินพุตที่ผสานแล้วซึ่งสร้างการดำเนินการเฉพาะ ซึ่งมีประโยชน์เมื่อความล้มเหลวขึ้นอยู่กับการผสานชุดอินพุต สาขาชุดอินพุตที่สำรองด้วย Git หรือค่าทริกเกอร์/รันไทม์ที่ยากต่อการสร้างใหม่จากหน้าเพจการดำเนินการเพียงอย่างเดียว

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

การตอบสนอง get ถูกฉายไปยัง:

• executionId - ID การดำเนินการแผนจาก resource_id
• inputSetYaml - YAML อินพุตรันไทม์ที่ผสานแล้วที่ใช้สำหรับการรัน หรือ null
• inputSetTemplateYaml - เทมเพลตอินพุตในเวลาดำเนินการ หรือ null
• resolvedYaml - YAML ที่แก้ไขนิพจน์เมื่อ resolve_expressions=true มิฉะนั้นมักจะเป็น null
• inputSetDetails - ชุดอินพุตที่บันทึกไว้ซึ่งมีส่วนร่วมเป็นคู่ { identifier, name }
• inputSetBranchName - สาขาต้นทางสำหรับชุดอินพุตที่สำรองด้วย Git หรือ null

execution_inputs เป็นแบบ get-only และมีความเสี่ยงในการอ่านต่ำ หากละเว้น resolve_expressions เซิร์ฟเวอร์จะละเว้นพารามิเตอร์คิวรีของ API และ Harness จะใช้โหมดการแก้ไข UNKNOWN เริ่มต้น

โหมดรอการดำเนินการไปป์ไลน์

สำหรับ pipeline.run, pipeline.retry และ pipeline_v1.run ให้ส่ง wait: true เพื่อให้เซิร์ฟเวอร์โพลจนกว่าการดำเนินการจะถึงสถานะสิ้นสุด ซึ่งช่วยให้การเปิดใช้ไปป์ไลน์และการตรวจสอบสถานะอยู่ในคำสั่งเครื่องมือเดียวแทนที่จะให้ไคลเอ็นต์หรือ LLM รันลูปการโพล

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

พฤติกรรมโหมดรอ:

• หมดเวลาเริ่มต้นคือ 600 วินาที ช่วงที่อนุญาตคือ 10 วินาทีถึง 7200 วินาที
• ช่วงโพลเริ่มต้นคือ 3 วินาที ถอยหลัง 1.5 เท่า และสูงสุดที่ 30 วินาที
• เมื่อสำเร็จหรือล้มเหลว การตอบสนองรวมฟิลด์เช่น execution_id, execution_status, execution_terminal, execution_elapsed_ms และ execution_poll_count
• หากหมดเวลา ทริกเกอร์เดิมยังคงสำเร็จ การตอบสนองรวม execution_timed_out: true และ _wait.hint พร้อมสถานะที่สังเกตล่าสุด
• หากการโพลล้มเหลวหลังจากทริกเกอร์สำเร็จ การตอบสนองรวม _wait.error และคำแนะนำการตรวจสอบซ้ำ อย่ารันไปป์ไลน์ซ้ำโดยไม่ไตร่ตรอง เว้นแต่คุณจะยืนยันแล้วว่าการดำเนินการแรกไม่ได้กำลังทำงาน
• สถานะสิ้นสุดที่ล้มเหลวรวมถึง _diagnose_hint ที่ชี้ไปยัง harness_diagnose(resource_type="execution", options={execution_id: "..."})

ขอให้ AI DevOps Agent สร้างไปป์ไลน์:

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

อัปเดตบริการผ่านภาษาธรรมชาติ:

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

โหมดการจัดเก็บไปป์ไลน์

ไปป์ไลน์ Harness สามารถจัดเก็บได้สามวิธี:

โหมด	คำอธิบาย	เมื่อใดควรใช้
Inline	YAML ไปป์ไลน์ที่เก็บใน Harness	ค่าเริ่มต้น การตั้งค่าง่ายที่สุด ไม่ต้องใช้ Git
Remote (External Git)	YAML ไปป์ไลน์ที่เก็บใน GitHub, GitLab, Bitbucket ฯลฯ	ทีมที่ใช้ pipeline-as-code ที่สำรองด้วย Git กับผู้ให้บริการภายนอก
Remote (Harness Code)	YAML ไปป์ไลน์ที่เก็บในที่เก็บ Harness Code	ทีมที่ใช้โฮสติ้ง Git ในตัวของ Harness

สร้างไปป์ไลน์ inline (ค่าเริ่มต้น):

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

สร้างไปป์ไลน์ remote (External Git — เช่น GitHub):

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

สร้างไปป์ไลน์ remote (Harness Code — ไม่ต้องใช้คอนเนกเตอร์):

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

อัปเดตไปป์ไลน์ 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"
  }
}

นำเข้าไปป์ไลน์จากที่เก็บ Git ภายนอก:

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

นำเข้าไปป์ไลน์จากที่เก็บ Harness Code:

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

สร้างคอนเนกเตอร์:

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

ลบทริกเกอร์:

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

รายการชุดอินพุตสำหรับไปป์ไลน์:

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

รับชุดอินพุตเฉพาะ:

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

สร้างชุดอินพุต:

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

อัปเดตชุดอินพุต:

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

ลบชุดอินพุต:

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

ประเภททรัพยากร

ประเภททรัพยากร 255 รายการจัดระเบียบในชุดเครื่องมือ 41 ชุด แต่ละประเภททรัพยากรสนับสนุนชุดย่อยของการดำเนินการ CRUD และการดำเนินการ execute ที่เป็นทางเลือก

แพลตฟอร์ม

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
organization	x	x	x	x	x
project	x	x	x	x	x

ไปป์ไลน์

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
pipeline	x	x	x	x	x	run, retry
pipeline_v1 (Alpha)	x	x	x	x	x	run
pipeline_dynamic_execution						run
execution	x	x				interrupt
execution_inputs		x
trigger	x	x	x	x	x
pipeline_summary		x
input_set	x	x	x	x	x
runtime_input_template		x
runtime_input_template_v1		x
pipeline_resolved_yaml		x
approval_instance	x					approve, reject

ประเภททรัพยากร YAML ไปป์ไลน์ทั้งสองมีให้ใช้งานเมื่อเปิดใช้งานชุดเครื่องมือไปป์ไลน์ HARNESS_PIPELINE_VERSION และส่วนหัวการเริ่มต้น HTTP x-harness-pipeline-version เลือกการตั้งค่าเวอร์ชันเริ่มต้น พวกเขาไม่ได้ซ่อนเวอร์ชันอื่น

เอเจนต์ AI

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
agent	x	x	x	x	x
agent_run	x

บริการ

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
service	x	x	x	x	x

สภาพแวดล้อม

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
environment	x	x	x	x	x	move_configs

คอนเนกเตอร์

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
connector	x	x	x	x	x	test_connection
connector_catalogue	x

โครงสร้างพื้นฐาน

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
infrastructure	x	x	x	x	x	move_configs

ความลับ

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
secret	x	x

บันทึกการดำเนินการ

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
execution_log		x

ร่องรอยการตรวจสอบ

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
audit_event	x	x

ตัวแทน

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
delegate	x	x
delegate_token	x	x	x		x	revoke, get_delegates

ที่เก็บโค้ด

ประเภททรัพยากร	List	Get	Create	Update	Delete	Execute Actions
repository	x	x	x	x
branch	x	x	x		x
commit	x	x	x			diff, diff_stats
file_content	x	x				blame
tag	x		x		x
repo_rule	x	x
space_rule	x	x

การสร้าง commit จะคอมมิตการดำเนินการไฟล์หนึ่งรายการขึ้นไปโดยตรงผ่าน Harness Code API โดยไม่ต้องโคลน ส่ง body.title, body.branch และ body.actions; แต่ละการดำเนินการคือ CREATE, UPDATE, DELETE หรือ MOVE และ UPDATE ต้องใช้ blob SHA ปัจจุบัน

รายการ file_content ส่งคืนทุกเส้นทางที่ ref; get ส่งคืนเนื้อหาไฟล์หรือไดเรกทอรี (ละเว้นหรือส่ง path ว่างสำหรับรากที่เก็บ; เส้นทางที่ซ้อนกันเก็บเครื่องหมายทับ) ละเว้น git_ref เพื่อใช้สาขาเริ่มต้นของที่เก็บ — อย่าเดา main

รีจิสทรีอาร์ติแฟกต์

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
registry	x	x
artifact	x
artifact_version	x
artifact_file	x

ที่เก็บไฟล์

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
file_store	x	x	x	x	x	list_children

file_store จัดการไฟล์และโฟลเดอร์ใน Harness File Store ผ่านเครื่องมือทั่วไป รองรับขอบเขตบัญชี องค์กร และโปรเจกต์ ส่ง resource_scope="account"|"org"|"project" หรือวาง URL ของ Harness File Store เพื่อให้เซิร์ฟเวอร์สามารถระบุขอบเขตและ ID ได้

การเรียกใช้งานทั่วไป:

# List the account-level File Store.
harness_list(resource_type="file_store", resource_scope="account")

# Create a folder at the current scope root.
harness_create(resource_type="file_store", body={
  name: "scripts",
  type: "FOLDER",
  parent_identifier: "Root"
})

# Upload a UTF-8 script file. Use content_base64 instead for binary data.
harness_create(resource_type="file_store", body={
  name: "deploy.sh",
  type: "FILE",
  parent_identifier: "Root",
  content: "#!/usr/bin/env bash\n./deploy",
  mime_type: "text/x-shellscript",
  file_usage: "SCRIPT"
})

# Rename metadata without replacing file content.
harness_update(resource_type="file_store", resource_id="deploy_script", body={
  name: "deploy-prod.sh",
  type: "FILE",
  parent_identifier: "Root"
})

# List first-level children of a folder. This is a read-risk execute action.
harness_execute(resource_type="file_store", action="list_children",
  resource_id="scripts_folder", params={folder_name: "scripts"})

ข้อจำกัดของเนื้อหาแบบ Multipart:

• การสร้าง/อัปเดตยอมรับ JSON body จากนั้นแปลงเป็น multipart/form-data สำหรับ /ng/api/file-store
• name, type (FILE หรือ FOLDER) และ parent_identifier เป็นข้อมูลที่จำเป็น ใช้ "Root" ตามตัวอักษรเท่านั้นสำหรับรากของขอบเขตที่เลือก
• การสร้าง FILE ต้องระบุอย่างใดอย่างหนึ่งระหว่าง content (สตริง UTF-8) หรือ content_base64 (base64 ที่ไม่ว่างและถูกต้อง) การอัปเดต FILE สามารถละเว้นเนื้อหาสำหรับการอัปเดตเฉพาะข้อมูลเมตา หรือระบุฟิลด์เนื้อหาหนึ่งฟิลด์เพื่อแทนที่เนื้อหา
• การสร้าง/อัปเดต FOLDER ต้องละเว้น content และ content_base64
• file_usage ที่ไม่บังคับต้องเป็น MANIFEST_FILE, CONFIG หรือ SCRIPT ข้อมูลเมตาแบบสเกลาร์ที่ไม่บังคับ เช่น description, mime_type, path และ tags ต้องเป็นสตริง
• เนื้อหาที่อัปโหลดจำกัดที่ 100 MB พร้อมท์ยืนยันจะปกปิดตัวอย่าง content, content_base64 และ contentBase64 ก่อนการสอบถาม

list_children ยอมรับรูปแบบย่อ (resource_id บวก params.folder_name หรือ params.file_store_id/params.folder_identifier บวก params.folder_name) หรือ FileStoreNode body เต็มรูปแบบพร้อม identifier, name และ type: "FOLDER" เนื้อหาเต็มใช้รูปแบบ camelCase ของ Harness parentIdentifier รูปแบบย่ออาจใช้ params.parent_identifier

เทมเพลต

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
template	x	x	x	x	x

การดำเนินการเทมเพลตใช้เส้นทางบริการ Template ของ Harness (/template/api/templates...) การสร้างและอัปเดตต้องใช้สตริง YAML เทมเพลตเต็มรูปแบบใน body.template_yaml หรือ body.yaml version_label กำหนดเป้าหมายเวอร์ชันเฉพาะสำหรับการอัปเดต/ลบ ในขณะที่การลบโดยไม่ใช้ version_label จะลบทุกเวอร์ชัน

แดชบอร์ด

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
dashboard	x	x
dashboard_data		x

Database DevOps

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
database_schema	x	x	x	x	x
database_instance	x	x	x	x	x
database_snapshot_object	x	x
database_llm_authoring_pipeline		x

การจัดการโครงสร้างพื้นฐานเป็นโค้ด (IaCM)

ทรัพยากร IaCM เปิดใช้งานตามค่าเริ่มต้นและส่วนใหญ่มีขอบเขตระดับโปรเจกต์ เริ่มต้นด้วย iacm_workspace เพื่อค้นหาตัวระบุเวิร์กสเปซ จากนั้นใช้ workspace_id นั้นสำหรับทรัพยากรเวิร์กสเปซ ค่าใช้จ่าย และความแตกต่างของกิจกรรม ใช้ iacm_variable_set สำหรับชุดตัวแปรที่นำกลับมาใช้ใหม่ได้ในขอบเขตบัญชี องค์กร หรือโปรเจกต์ รีจิสทรีผู้ให้บริการมีขอบเขตระดับบัญชี

iacm_module ครอบคลุมขอบเขตบัญชี องค์กร และโปรเจกต์ โดยค่าเริ่มต้นจะใช้รีจิสทรีระดับบัญชี ทุกการดำเนินการ (รายการ ดู สร้าง อัปเดต) ส่งพารามิเตอร์คิวรี scope_org / scope_project เดียวกัน ดังนั้นโมดูลที่คุณสร้างจะค้นพบได้ในขอบเขตที่คุณสร้าง เลือกขอบเขตด้วย resource_scope="account" | "org" | "project" บวก org_id/project_id การกำหนดขอบเขตเป็นแบบเลือกใช้: เมื่อละเว้น resource_scope ค่า org_id/project_id จะใช้เฉพาะเมื่อคุณส่งอย่างชัดเจนเท่านั้น — ค่าเริ่มต้น HARNESS_ORG/HARNESS_PROJECT ที่กำหนดค่าไว้จะไม่ถูกนำไปใช้ ดังนั้นการกำหนดค่าโปรเจกต์โดยรอบจะไม่สามารถลงทะเบียนโมดูลบัญชีภายใต้โปรเจกต์อย่างเงียบๆ ได้ ฟิลด์ org/project ของเนื้อหาโมดูลเองใช้ระบุตำแหน่ง Git connector และไม่เกี่ยวข้องกับขอบเขตการมองเห็นนี้

การสร้าง/อัปเดต iacm_workspace คืนค่า { policy_evaluation } เท่านั้น — ตามด้วย harness_get เพื่อดึงเวิร์กสเปซ การสร้าง/อัปเดต iacm_variable_set และ iacm_module คืนค่าทรัพยากรเอง การสร้าง iacm_provider คืนค่า { id } เท่านั้น — ตามด้วย harness_get การอัปเดตเป็นแบบเน้นเวอร์ชันเท่านั้น (POST/PUT /providers/{id}/version) — ไม่มี PUT สำหรับข้อมูลเมตา การเขียนเวอร์ชันอาจคืนค่าเนื้อหาว่าง HarnessClient จะปรับให้เป็น { status: "SUCCESS", message: "No content" }

การอัปเดตชุดตัวแปรเป็น HTTP PUT พร้อมคอลเลกชันแทนที่ทั้งหมด — เรียก harness_get ก่อนเสมอ จากนั้น PUT เนื้อหาที่ต้องการทั้งหมด (terraform_variables / environment_variables จำเป็นในการอัปเดต การละเว้น/ว่างจะล้าง connector และไฟล์ตัวแปร) การอัปเดตโมดูลเป็น PUT เช่นกัน — ควรใช้ get-then-put สำหรับฟิลด์ที่ไม่บังคับ การเขียนเป็น medium_write และต้องยืนยัน (การสอบถามหรือ confirm: true)

RBAC ของชุดตัวแปรและรีจิสทรีผู้ให้บริการ (iac_variableset_*, iac_providerregistry_*) อยู่ในสถานะ Experimental ใน Harness — การตรวจสอบการเข้าถึงอนุญาตเสมอจนกว่า iac-server จะเปิดใช้งานการบังคับใช้ RBAC ของรีจิสทรีโมดูล (iac_registry_view / iac_registry_edit) อยู่ในสถานะ Active และบังคับใช้ได้ MCP ส่งต่อ PAT/SAT ของผู้เรียกเสมอโดยไม่เปลี่ยนแปลง

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
iacm_workspace	x	x	x	x
iacm_variable_set	x	x	x	x
iacm_resource	x
iacm_module	x	x	x	x
iacm_provider	x	x	x	x
iacm_workspace_costs	x
iacm_activity_resource_change	x

ขั้นตอนการทำงานทั่วไป:

1. harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") เพื่อค้นหาเวิร์กสเปซ
2. harness_create / harness_update บน iacm_workspace เพื่อสร้างจากศูนย์หรือจากเทมเพลต (associated_template) หรืออัปเดตเวิร์กสเปซที่มีอยู่ — การตอบสนองเป็น { policy_evaluation } เท่านั้น
3. harness_get(resource_type="iacm_workspace", workspace_id="...") เพื่อดึงเวิร์กสเปซที่สร้าง/อัปเดต
4. harness_list / harness_create / harness_update บน iacm_variable_set (อาจมี resource_scope) สำหรับชุดตัวแปร Terraform/env ที่นำกลับมาใช้ใหม่ได้ — การตอบสนองเป็นทรัพยากร VariableSet
5. harness_list / harness_create / harness_update บน iacm_module สำหรับรีจิสทรีโมดูล (ต้องมี name + system เพิ่ม resource_scope พร้อม org_id/project_id สำหรับโมดูลระดับองค์กรหรือโปรเจกต์) — การตอบสนองเป็นทรัพยากรโมดูล
6. harness_list / harness_create / harness_update บน iacm_provider สำหรับรีจิสทรีผู้ให้บริการระดับบัญชี (ต้องมี body.type สำหรับการสร้าง การสร้างคืนค่า { id } เท่านั้น — จากนั้น harness_get การอัปเดตสร้าง/อัปเดตเวอร์ชันเท่านั้น) — การอัปเดตเวอร์ชันอาจคืนค่าความสำเร็จว่างเปล่า
7. harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") เพื่อตรวจสอบทรัพยากร Terraform ผลลัพธ์ และแหล่งข้อมูล
8. harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") เพื่อตรวจสอบรายการค่าใช้จ่ายต่อการดำเนินการ
9. harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") เพื่อตรวจสอบความแตกต่างของทรัพยากรก่อน/หลังสำหรับแผน การนำไปใช้ หรือกิจกรรมการทำลาย

การตอบสนองรายการ IaCM เปิดเผย page_count เป็นจำนวนสำหรับหน้าปัจจุบันเท่านั้น (ยกเว้น iacm_variable_set ซึ่งไม่มีการแบ่งหน้า) เมื่อ has_more เป็นจริง ให้ขอหน้าถัดไปตามลำดับ 1-based ต่อไปและรวมจำนวนหน้าหากคุณต้องการยอดรวม

พอร์ทัลนักพัฒนาภายใน (IDP)

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
idp_entity	x	x
scorecard	x	x
scorecard_check	x	x
scorecard_stats		x
scorecard_check_stats		x
idp_score	x	x
idp_workflow	x					execute
idp_tech_doc	x

คำขอดึง (Pull Requests)

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
pull_request	x	x	x	x		close, merge
pr_reviewer	x		x			submit_review
pr_comment			x	x	x
pr_check	x
pr_activity	x

ใช้ harness_execute(resource_type="pull_request", action="close", ...) สำหรับการดำเนินการปิดอย่างชัดเจน harness_update ยังยอมรับ body.state (open หรือ closed) และส่งการเปลี่ยนแปลงสถานะไปยัง endpoint สถานะ PR ของ Harness Code โดยเฉพาะ ส่งการแก้ไขชื่อเรื่อง/คำอธิบายในการเรียกอัปเดตแยกต่างหาก

ใช้ harness_list(resource_type="pr_activity", filters={type: ["comment", "code-comment"]}, ...) เพื่ออ่านความคิดเห็น PR ใช้ pr_comment สำหรับการดำเนินการเขียนความคิดเห็น

การจัดการการเผยแพร่

ทรัพยากรการจัดการการเผยแพร่ (RMG) เปิดใช้งานตามค่าเริ่มต้น ทรัพยากรคำจำกัดความ (release_process, release_activity) รองรับรายการ/ดู/สร้าง/อัปเดต/ลบด้วย body.yaml เรียก harness_schema(resource_type="release_process"|"release_activity") ก่อนสร้าง/อัปเดต ทรัพยากรการดำเนินการตรวจสอบการเผยแพร่ที่กำลังทำงาน — การดำเนินการรายการส่วนใหญ่ต้องใช้ release_id (UUID จาก harness_list resource_type=release หรือ slug URL UI เช่น identifier-1.0.0-abc) วาง URL การเผยแพร่ RMG ลงใน harness_list เพื่อเติม release_id อัตโนมัติ

การเรียก RMG ใช้ ${HARNESS_BASE_URL}/gateway/rmg พร้อมการกำหนดขอบเขตบัญชีผ่านส่วนหัว Harness-Account ขอบเขตองค์กร/โปรเจกต์ใช้การกำหนดขอบเขตตามส่วนหัวเมื่อระบุ org_id/project_id release_execution_phase เป็นแบบรายการเท่านั้น — ใช้ฟิลด์ identifier ของแต่ละรายการเฟสเป็น params.phase_identifier เมื่อเรียก harness_get บนทรัพยากรอินพุต/เอาต์พุตเฟส (อย่าเรียก harness_get บน release_execution_phase เอง) การกรอง status ของรายการเผยแพร่ใช้ฝั่งไคลเอ็นต์เฉพาะหน้าปัจจุบันเท่านั้น ดำเนินการแบ่งหน้าต่อด้วยตัวกรองเดียวกันเมื่อผลลัพธ์อาจครอบคลุมหลายหน้า

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
release_process	x	x	x	x	x
release_activity	x	x	x	x	x
release	x	x
release_execution_phase	x
release_execution_task	x
release_execution_activity	x
release_input		x
release_execution_phase_input		x
release_execution_phase_output		x
release_execution_activity_input		x
release_execution_activity_output		x

ขั้นตอนการทำงานทั่วไป:

1. ใช้ harness_list(resource_type="release_process", org_id="...", project_id="...") เพื่อค้นหาคำจำกัดความของกระบวนการ orchestration
2. ใช้ harness_schema(resource_type="release_process") (หรือ release_activity) ก่อนการสร้าง/อัปเดต จากนั้นใช้ harness_create / harness_update พร้อมกับ body.yaml
3. ใช้ harness_list(resource_type="release", org_id="...", project_id="...") เพื่อค้นหารีลีสที่ใช้งานอยู่หรือล่าสุด (ค่าเริ่มต้นคือย้อนหลัง 30 วัน; ตัวเลือกเสริม filters.status, filters.search_term, filters.days_back)
4. ใช้ harness_get(resource_type="release", release_id="...") สำหรับรายละเอียดรีลีส
5. ใช้ harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) สำหรับสถานะเฟส; ใช้ release_id เดียวกันสำหรับ release_execution_task และ release_execution_activity
6. ใช้ harness_get บน release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_output, หรือ release_execution_activity_input โดยใช้ release_id ร่วมกับ params.phase_identifier / params.activity_identifier / activity_execution_id ตามที่ระบุไว้ในแต่ละทรัพยากร

ภาพรวม (Vibe)

ชุดเครื่องมือ vibe ที่เปิดใช้งานตามค่าเริ่มต้นครอบคลุม สัญญา Vibe Orchestrator BFF ภายใต้ ${HARNESS_BASE_URL}/vibe/v1 โดยใช้การเชื่อมต่อ Harness และส่วนหัวบัญชีที่มีอยู่ โดยไม่เพิ่มพารามิเตอร์ query ของบัญชี/องค์กร/โปรเจกต์หรือฟิลด์ขอบเขตใน request body ทีมงานได้ตรวจสอบความถูกต้องของโฟลว์ Vibe โดยใช้การรับรองความถูกต้องด้วย API key ของ Harness (PAT/SAT) ดังนั้นจึงไม่จำเป็นต้องตั้งค่า opt-in สำหรับเซสชันเริ่มต้น เอกสาร OpenAPI ที่คัดสรรแล้วระบุการรับรองความถูกต้องแบบ bearer/session; โหมด OAuth ของเซิร์ฟเวอร์จะส่งต่อ bearer token ของเซสชันปัจจุบัน การทดสอบอัตโนมัติตรวจสอบเส้นทางส่วนหัวทั้งสอง; การรับรองความถูกต้องผ่านเกตเวย์ยังคงขึ้นอยู่กับการกำหนดค่าของสภาพแวดล้อมเป้าหมาย

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
vibe_project			x			prepare, deploy
vibe_app_lifecycle		x				events

API รองรับเส้นทางการรับข้อมูลสองเส้นทาง รักษารูปแบบ request ที่เป็นธรรมชาติของ API ไว้ดังนี้:

แหล่งที่มาที่พร้อมใช้งานสำหรับ coding agent	โฟลว์ API
ลิงก์/connector ของที่เก็บ GitHub	harness_create พร้อมกับ resource_type="vibe_project" และ body.mode รวมถึงฟิลด์เฉพาะโหมด สัญญากำหนดชื่อ github_link และ github_connector แต่ไม่ได้กำหนดรูปแบบ URL, branch, หรือ connector field; ฟิลด์เหล่านี้จะถูกส่งต่อไปยัง backend โดยไม่มีการสร้าง mapping ขึ้นเอง
ไฟล์ ZIP	เรียก prepare พร้อมกับชื่อแอปและข้อมูลเมตาของไฟล์ อัปโหลดไบต์ไปยัง signed target ที่ส่งกลับ จากนั้นเรียก deploy
ไดเรกทอรีซอร์สในเครื่อง	coding agent บีบอัดซอร์สของ workspace ที่ต้องการลงใน ZIP ในเครื่อง จากนั้นทำตามโฟลว์ ZIP เส้นทางในเครื่องหรือบริบทการสนทนาไม่ใช่แหล่งอัปโหลดที่ API รองรับ

เมื่อแพ็กเกจไดเรกทอรี ให้รวมซอร์ส, manifests, lockfiles, การกำหนดค่า และการแก้ไขที่ยังไม่ได้ commit ที่ต้องการเพื่อสร้างมัน ไม่รวมข้อมูลรับรอง, .git, dependencies ที่ติดตั้งแล้ว และ artifacts ที่สร้างขึ้น การแพ็กเกจและการอัปโหลดแบบ signed เกิดขึ้นที่ตำแหน่งที่ไฟล์เข้าถึงได้; เซิร์ฟเวอร์ MCP ที่โฮสต์ไม่สามารถอ่านไดเรกทอรีในเครื่องของ coding agent ได้

สำหรับ ZIP ที่มีอยู่แล้ว ให้เตรียมการอัปโหลด:

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

ส่งค่านี้ไปยัง harness_execute ขนาดต้องอธิบาย ZIP จริง; size_bytes, content_type, และ md5 เป็นตัวเลือกและสามารถเป็น null ได้ ฟิลด์ prepare เพิ่มเติมจะถูกเก็บไว้สำหรับการตรวจสอบ backend ตามที่ OpenAPI อนุญาต การเตรียมการส่งกลับ projectId, sourceId, และ upload รวมถึง uploadUrl, method, headers, และ expiresAt ของแต่ละไฟล์ อัปโหลดไบต์ไฟล์โดยตรงโดยใช้ signed URL, method, และ headers นั้น; รักษา URL ไว้ตามเดิมทุกประการและอย่าเพิ่มข้อมูลรับรอง Harness ลงในคำขอ storage การดำเนินการ prepare ไม่ได้อ่านหรืออัปโหลดไฟล์ในเครื่อง

หลังจากการอัปโหลดสำเร็จ ให้ดำเนินการ deploy อย่างชัดเจน:

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

สำหรับการนำเข้า JSON ให้ใช้ id ที่ส่งกลับแทน การ deploy ยังยอมรับ body: {"project_id": "<Vibe app id>"} หรือ params.app_id; ฟิลด์ wire ของ API เป็น snake_case project_id แม้ว่า prepare จะส่งกลับ camelCase projectId ก็ตาม project_id ระดับบนสุดของเครื่องมือทั่วไปเป็นตัวระบุขอบเขต Harness และไม่เคยใช้เป็น ID แอป Vibe การนำเข้าและ prepare สร้างแอป/ซอร์ส; ทั้งคู่ไม่ได้เริ่มการ deploy การเขียนจะไม่ถูก retry โดยอัตโนมัติ และการ deploy ใช้นโยบายการยืนยันความเสี่ยงสูงที่มีอยู่

อ่านความคืบหน้าด้วย harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>") โดยจะเก็บ URL แอป, ขั้นตอนการดำเนินการ, substeps, ความล้มเหลว, บรรทัดล็อก และรายละเอียด build-analyzer การดำเนินการ execute ของ events ยอมรับ resource_id หรือ params.app_id และใช้ SSE endpoint เป็นชุดที่มีขอบเขตจำกัด: สูงสุด 20 อีเวนต์ JSON หรือห้าวินาทีหลังการเชื่อมต่อ โดยมีขีดจำกัดการตอบสนอง 1 MiB ขีดจำกัดเหล่านี้เป็นของ Vibe endpoint HARNESS_API_TIMEOUT_MS ของการเชื่อมต่อยังจำกัดการเชื่อมต่อและการบริโภคสตรีมร่วมกัน; การหมดอายุส่งกลับข้อผิดพลาด timeout ชุดที่เสร็จสมบูรณ์ส่งกลับ events และ stop_reason (end, event_limit, หรือ duration_limit) และปิดสตรีม ทั้งความล้มเหลวในการเชื่อมต่อเริ่มต้นและสตรีมที่ขาดจะไม่ถูก retry อีเวนต์เป็น diff ชั่วคราวที่ไม่มี replay cursor ที่บันทึกไว้; ใช้ lifecycle get สำหรับ snapshot ที่เชื่อถือได้ การอ่าน lifecycle ทั้งสองมีให้ในโหมดอ่านอย่างเดียว

Feature Flags

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ
fme_workspace	x
fme_environment	x	x	x	x	x
fme_feature_flag	x	x	x	x	x	kill, restore, reallocate, archive, unarchive
fme_feature_flag_definition	x	x	x	x	x	kill, restore, reallocate
fme_rollout_status	x
fme_rule_based_segment	x	x	x		x
fme_rule_based_segment_definition	x			x		enable, disable, change_request
fme_traffic_type	x
fme_identity			x	x
fme_standard_segment	x	x
fme_segment_keys	x			x
fme_segment	x	x	x	x	x
fme_segment_definition	x	x	x	x	x	list_keys, add_keys, remove_keys
fme_metric	x	x	x	x	x
fme_event_type	x	x

ทรัพยากร FME (Split.io) — ทรัพยากร fme_* รองรับ การกำหนดขอบเขตแบบสองโหมด: การเรียกแบบเดิมส่ง workspace_id และเข้าถึง Split.io API (api.split.io); การเรียกแบบใหม่ส่ง org_id+project_id พร้อมกันและเข้าถึง endpoint ดั้งเดิมของ Harness (HARNESS_API_KEY/HARNESS_BASE_URL มาตรฐาน, การรับรองความถูกต้องเดียวกันกับทรัพยากร harness_* อื่นๆ ทั้งหมด) แทน การส่งทั้ง workspace_id และ org_id/project_id ในการเรียกเดียวกัน หรือการผสม org_id กับ project_id เพียงอย่างเดียว เป็นข้อผิดพลาด — เลือกหนึ่งโหมดต่อการเรียก ทุกการดำเนินการด้านล่างมีให้ในโหมดเดิม โดยไม่มีการเปลี่ยนแปลง เว้นแต่ทรัพยากรจะถูกทำเครื่องหมายว่าเป็น Harness-native เท่านั้น ความครอบคลุมของโหมด Harness-native ในปัจจุบันยังแคบกว่า:

• fme_workspace — ไม่มีสิ่งที่เทียบเท่าแบบ Harness-native; รองรับเฉพาะระบบเดิม (ใช้เพื่อค้นหาค่า workspace_id)

• fme_environment — โหมดคู่ list (workspace_id หรือ org_id+project_id) get/create/update/delete เป็นแบบ Harness-native เท่านั้น (/fme/api/v4/environments) — MCP ไม่เคยมีสัญญา workspace_id สำหรับการดำเนินการเหล่านั้น รายการแบบเนทีฟใช้ offset/limit แบบไม่บังคับ (สูงสุด 100; harness_list size แมปไปยัง limit); ซองจดหมาย {data, limit, offset, totalCount} ถูกเลื่อนขั้นเป็น items/total การสร้าง/อัปเดตแบบเนทีฟใช้ isProduction (ยอมรับ production เป็นนามแฝง) การอัปเดตแบบเนทีฟเป็น JSON Merge Patch; name และ isProduction ไม่สามารถล้างค่าได้ ชื่อสูงสุด 15 ตัวอักษร

• fme_feature_flag — โหมดคู่ ทั้งสองสาขาเชื่อมต่อครบถ้วน Harness-native (org_id+project_id): list/get/create/delete เรียก /fme/api/v4/feature-flags (body สำหรับ create: name, trafficType, description/tags/owners แบบไม่บังคับ, ตาม CreateFeatureFlagRequest); update ส่ง merge-patch ไปยัง /fme/api/v4/feature-flags/{name}; archive/unarchive เรียก /fme/api/v4/feature-flags/{name}/archive|unarchive (เฉพาะ comment แบบไม่บังคับ — ไม่มี title, ตาม ArchiveUnarchiveRequest); kill/restore/reallocate เรียก /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate โดยมี environment_id เป็นพารามิเตอร์ query (comment/title แบบไม่บังคับ, ตาม FeatureFlagDefinitionActionRequest)

• fme_feature_flag_definition — get/create/update ยังคงเป็นโหมดคู่ (workspace_id หรือ org_id+project_id) list/delete/kill/restore/reallocate เป็นแบบ Harness-native เท่านั้น (org_id+project_id) — MCP ไม่เคยมีสัญญา workspace_id สำหรับการดำเนินการเหล่านั้น รายการแบบเนทีฟต้องใช้ feature_flag_name และใช้ offset/limit (ค่าเริ่มต้น 100, สูงสุด 100); ไม่รับ environment_id การลบและการดำเนินการต้องใช้ environment_id Kill/restore/reallocate เป็นการดำเนินการเดียวกันกับบน fme_feature_flag body ของ get/create/update ตรงกับระบบเดิม (treatments, defaultTreatment, defaultRule, rules/baselineTreatment/trafficAllocation/comment แบบไม่บังคับ) บวกกับ title แบบไม่บังคับในโหมด Harness-native การอัปเดตแบบเนทีฟเป็น JSON Merge Patch

• fme_rollout_status — list แบบโหมดคู่ ส่ง org_id+project_id (แนะนำ) หรือ workspace_id ที่เลิกใช้แล้ว การแบ่งหน้าแบบเนทีฟใช้ offset/limit (สูงสุด 100; harness_list size แมปไปยัง limit); ผลลัพธ์ถูกเลื่อนขั้นเป็น items/total แต่ละรายการมี id, name และ description แบบไม่บังคับ

• fme_rule_based_segment — (เลิกใช้แล้ว — ดู fme_segment) โหมด Harness-native ถูกปฏิเสธในทุกการดำเนินการ (list/get/create/delete) — ใช้ fme_segment แทน; ทรัพยากรนี้รองรับเฉพาะสัญญา workspace_id แบบเดิม

• fme_rule_based_segment_definition — (เลิกใช้แล้ว — ดู fme_segment_definition) โหมด Harness-native ถูกปฏิเสธในทุกการดำเนินการ/แอ็กชัน (list/update/enable/disable/change_request) — ใช้ fme_segment_definition แทน (ไม่มี enable/disable/change_request ที่เทียบเท่ากันที่นั่น); ทรัพยากรนี้รองรับเฉพาะสัญญา workspace_id/environment_id แบบเดิม

• fme_traffic_type — list แบบโหมดคู่ ส่ง org_id+project_id (แนะนำ) หรือ workspace_id ที่เลิกใช้แล้ว การแบ่งหน้าแบบเนทีฟใช้ offset/limit (สูงสุด 100; harness_list size แมปไปยัง limit); ผลลัพธ์ถูกเลื่อนขั้นเป็น items/total แต่ละรายการมี id และ name (ไม่มี displayAttributeId)

• fme_identity — create/update ยังไม่ได้ถูกนำไปใช้หากส่ง org_id+project_id พร้อมกัน; มิฉะนั้นจะดำเนินการเป็นการเรียกแบบเดิมตามปกติ

• fme_standard_segment — เลิกใช้แล้ว workspace_id แบบเดิมยังคงเรียก Split v2 Harness-native ถูกปฏิเสธ — ใช้ fme_segment

• fme_segment_keys — list/update ยังคงเป็นแบบเดิม (workspace_id / environment_id+segment_name) Harness-native (org_id+project_id) ถูกปฏิเสธ — ใช้ fme_segment_definition ดำเนินการ list_keys/add_keys/remove_keys

• fme_segment — แบบเนทีฟเท่านั้น (org_id+project_id) CRUD list/get/update/delete ต้องใช้ segment_type: STANDARD | LARGE | RULE_BASED body การสร้าง: name, trafficType, segmentType; description, tags, owners แบบไม่บังคับ

• fme_segment_definition — แบบเนทีฟเท่านั้น CRUD บวกกับการดำเนินการ list_keys/add_keys/remove_keys การอัปเดตเป็นคำอธิบายเท่านั้น การลบล้มเหลวด้วย hasDependents ในขณะที่คีย์ยังคงอยู่

• fme_metric — Harness-native เท่านั้น (ไม่รองรับ workspace_id แบบเดิม) list/get/create/update/delete เชื่อมต่อกับ /fme/api/v4/metrics (harness_list size ของ list แมปไปยัง limit) create ต้องใช้ spread แม้ว่าแบ็กเอนด์ CreateMetricRequest จะเก็บเป็นตัวเลือก (ค่าเริ่มต้น PER) — เป็นสัญญาที่เข้มงวดกว่าเฉพาะฝั่ง MCP เนื่องจากการละเว้นจะเปลี่ยนความหมายของเมตริก RATE อย่างเงียบ ๆ update เป็น JSON Merge Patch; name/trafficType ไม่เปลี่ยนค่าและไม่ได้รับการยอมรับ delete เป็นการลบถาวร (ไม่มี archive/restore) — จัดประเภทเป็น destructive

• fme_event_type — Harness-native เท่านั้น (ไม่รองรับ workspace_id แบบเดิม) อ่านอย่างเดียว: list/get เชื่อมต่อกับ /fme/api/v4/event-types; id คือชื่ออีเวนต์ เฉพาะประเภทอีเวนต์ที่มีอีเวนต์ใน 30 วันที่ผ่านมาเท่านั้นที่มองเห็นได้; get คืนค่า 404 สำหรับประเภทอีเวนต์ที่อยู่นอกขอบเขต traffic-type ของเวิร์กสเปซที่ร้องขอ หรือไม่ได้ใช้งานนานกว่า 30 วัน ตัวกรองรายการ: name (สตริงย่อย), traffic_type (ตาม ID หรือชื่อ), offset/limit (harness_list size แมปไปยัง limit) ใช้สิ่งนี้เพื่อค้นหา ID ประเภทอีเวนต์จริงก่อนอ้างอิงใน baseEventTypes/filterEventType หรือตัวกรอง event_type_ids ของ fme_metric แทนการเดา ID

ในโหมดผู้ใช้คนเดียว/โฮสต์เอง การรับรองความถูกต้องแบบโหมดเดิมใช้ Bearer token จาก HARNESS_FME_API_KEY โดยจะถอยกลับไปใช้ HARNESS_API_KEY ที่ไม่ใช่ตัวยึดตำแหน่ง HARNESS_FME_API_KEY อาจเป็นคีย์ผู้ดูแลระบบ Split แบบเดิมหรือ Harness PAT/SAT ที่มีสิทธิ์ FME แต่จะถูกปฏิเสธในโหมด multi-user เพื่อให้การปรับใช้แบบแชร์ไม่สามารถแทนที่ข้อมูลประจำตัวของผู้ใช้แต่ละเซสชันได้ ข้อมูลประจำตัว OAuth/การกำหนดเส้นทางบริการแบบโฮสต์สำหรับ Harness platform API ไม่รับรองความถูกต้องของคำขอ Split.io โดยตรง fme_feature_flag รองรับการจัดการวงจรชีวิตเต็มรูปแบบในโหมดเดิม: สร้าง (ต้องใช้ traffic_type_id), รายการ, รับ, อัปเดตเมทาดาทา, ลบ และดำเนินการ kill/restore/reallocate/archive/unarchive ใช้ fme_traffic_type เพื่อค้นหา ID ประเภท traffic, fme_identity เพื่อสร้าง/อัปเดตแอตทริบิวต์ข้อมูลประจำตัว และ fme_standard_segment / fme_segment_keys เพื่อตรวจสอบเซ็กเมนต์มาตรฐานและเพิ่มคีย์สมาชิก fme_rule_based_segment ให้ CRUD สำหรับเซ็กเมนต์เป้าหมาย ในขณะที่ fme_rule_based_segment_definition จัดการกฎเซ็กเมนต์เฉพาะสภาพแวดล้อมด้วยโฟลว์การเปิด/ปิดใช้งานและการอนุมัติคำขอเปลี่ยนแปลง

GitOps

ประเภททรัพยากร	รายการ	รับ	สร้าง	อัปเดต	ลบ	ดำเนินการแอ็กชัน
gitops_agent	x	x
gitops_argo_project	x
gitops_app_project_mapping	x		x	x	x	import
gitops_autocreate_log	x
gitops_application	x	x				sync
gitops_cluster	x	x
gitops_repository	x	x
gitops_applicationset	x	x
gitops_repo_credential	x	x
gitops_app_event	x
gitops_pod_log		x
gitops_managed_resource	x
gitops_resource_action	x
gitops_dashboard		x
gitops_app_resource_tree		x
gitops_cluster_link	x		x		x

Chaos Engineering

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ Actions
chaos_experiment	x	x	x		x	run, stop
chaos_experiment_run		x
chaos_experiment_variable	x
chaos_component_variable		x
chaos_input_set	x	x	x	x	x
chaos_experiment_template	x	x			x	create_from_template, list_revisions, get_variables, get_yaml, compare_revisions
chaos_probe	x	x	x		x	enable, verify, get_manifest
chaos_probe_in_run	x
chaos_probe_template	x	x			x	get_variables
chaos_infrastructure	x
chaos_k8s_infrastructure	x	x	x			check_health
chaos_enabled_infrastructure	x
chaos_environment	x
chaos_hub	x	x	x	x	x
chaos_hub_fault	x
chaos_fault	x	x			x	get_variables, get_yaml
chaos_fault_template	x	x			x	list_revisions, get_variables, get_yaml, compare_revisions
chaos_fault_experiment_run	x
chaos_action	x	x	x		x	get_manifest
chaos_action_template	x	x			x	list_revisions, get_variables, compare_revisions
chaos_loadtest	x	x	x	x	x	run, stop
chaos_service	x	x	x	x	x	list_experiment_runs, list_load_tests
chaos_application_map	x	x
discovered_agent	x
discovered_namespace	x
discovered_service	x
discovered_network_map	x
chaos_guard_condition	x	x			x
chaos_guard_rule	x	x			x	enable
chaos_recommendation	x	x
chaos_risk	x	x
chaos_dr_test	x		x
scanned_risk	x	x				occurrences, summary_by_service
chaos_risk_rule	x	x
chaos_risk_scan	x	x	x	x	x	retry, abort, report, report_download, heatmap

การจัดการต้นทุนคลาวด์ (CCM)

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ Actions
cost_perspective	x	x	x	x	x
cost_breakdown	x
cost_timeseries	x
cost_summary	x	x
cost_recommendation	x	x				update_state, override_savings, create_jira_ticket, create_snow_ticket
cost_anomaly	x
cost_anomaly_summary		x
cost_category	x	x
cost_account_overview		x
cost_filter_value	x
cost_recommendation_stats		x
cost_recommendation_detail		x
cost_commitment		x
ai_budget	x	x	x	x	x
ai_budget_overview		x
ai_budget_consumption	x
ai_budget_override_request	x	x	x			approve, reject

ข้อมูลเชิงลึกทางวิศวกรรมซอฟต์แวร์ (SEI)

ทรัพยากร SEI ถูกรวมเข้าด้วยกันเพื่อประสิทธิภาพของโทเค็น ใช้พารามิเตอร์ metric หรือ aspect สำหรับรายละเอียด DORA, ทีม/โครงสร้างองค์กร และข้อมูลเชิงลึก AI

ประเภททรัพยากร	รายการ	ดู	สร้าง	อัปเดต	ลบ	ดำเนินการ Actions
sei_metric	x
sei_productivity_metric		x
sei_dora_metric		x				ส่ง metric: deployment_frequency, change_failure_rate, mttr, lead_time, หรือ *_drilldown
sei_team	x	x
sei_team_detail	x					ส่ง aspect: integrations, developers, integration_filters
sei_org_tree	x	x
sei_org_tree_detail	x	x				ส่ง aspect: efficiency_profile, productivity_profile, business_alignment_profile, integrations, teams
sei_business_alignment	x	x				ส่ง aspect: feature_metrics, feature_summary, drilldown สำหรับการดู
sei_ai_usage	x	x				ส่ง aspect: metrics, breakdown, summary, top_languages
sei_ai_adoption	x	x				ส่ง aspect: metrics, breakdown, summary
sei_ai_impact		x				ส่ง aspect: pr_velocity, rework
sei_ai_raw_metric	x

การรับประกันซอฟต์แวร์ซัพพลายเชน (SCS)

ประเภททรัพยากร	รายการ	ดูรายละเอียด	สร้าง	อัปเดต	ลบ	ดำเนินการ
scs_artifact_source	x
artifact_security	x	x
scs_artifact_component	x
scs_artifact_remediation		x
scs_chain_of_custody		x
scs_compliance_result	x
code_repo_security	x	x
scs_sbom		x

Evidence Vault

Evidence Vault เก็บ attestation แบบ in-toto (หลักฐาน SDLC) การแสดงรายการรองรับขอบเขตบัญชี/องค์กร/โปรเจกต์ผ่าน resource_scope ตัวกรองข้อความอิสระแบบเอกพจน์ (ไปป์ไลน์, อาร์ติแฟกต์อย่างเดียว, gitoid) ใช้ search_term; ข้อจำกัดชื่อเพิ่มเติมใช้ filters.subject_name; digest เนื้อหาของ subject ใช้ filters.subject_digest การดูรายละเอียดค้นหาด้วย gitoid_sha256 และต้องระบุ org_id/project_id (จากแถวในรายการ) การดาวน์โหลด (harness_execute action download) คืนค่า download_url ที่มีเวลาจำกัด — ควรแสดงลิงก์นั้นให้ผู้ใช้เสมอ ต้องเปิดใช้ feature flag SCS_EVIDENCE_VAULT

ประเภททรัพยากร	รายการ	ดูรายละเอียด	สร้าง	อัปเดต	ลบ	ดำเนินการ
attestation	x	x				download

Security Testing Orchestration (STO)

ประเภททรัพยากร	รายการ	ดูรายละเอียด	สร้าง	อัปเดต	ลบ	ดำเนินการ
security_issue	x
security_issue_filter	x
security_exemption	x		x			approve, reject
remediation_diff	x

การสร้าง security_exemption เป็นการดำเนินการแบบ high_write เซิร์ฟเวอร์จะดึง requester_id จาก PAT ที่ผ่านการตรวจสอบสิทธิ์ ตั้งค่า exemptFutureOccurrences=true และกำหนดค่าเริ่มต้น duration_days เป็น 30 เมื่อไม่มีการระบุ สำหรับการแสดงรายการ exemptions ให้ส่งขนาดหน้าเว็บเล็ก ๆ อย่างชัดเจน (เช่น filters: { "status": "Pending", "size": 5 }) และปฏิบัติตาม _nextPageHint ที่ส่งกลับในแต่ละการตอบสนอง

ขั้นตอนการดำเนินการ security exemption:

• ใช้ harness_list กับ resource_type="security_exemption" และ status ที่ชัดเจน เช่น Pending, Approved, Rejected, Expired, หรือ Canceled
• ใช้ harness_execute กับ action="approve" และ body.scope ที่จำเป็น: CURRENT, ACCOUNT, ORG, หรือ PROJECT CURRENT อนุมัติที่ขอบเขตเดิมของ exemption; ขอบเขตอื่น ๆ ใช้ STO promote endpoint ภายใน เซิร์ฟเวอร์จะเติม body.approver_id จากผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์โดยอัตโนมัติเมื่อไม่ระบุ; body.comment เป็นตัวเลือก
• ใช้ action="reject" เพื่อปฏิเสธ exemption body.approver_id จะถูกเติมโดยอัตโนมัติเมื่อไม่ระบุเช่นกัน
• ไม่มี promote execute action แยกต่างหาก ใช้ action="approve" กับ body.scope ที่ไม่ใช่ CURRENT เมื่อผลลัพธ์ที่ต้องการคือการอนุมัติที่ขอบเขตบัญชี องค์กร หรือโปรเจกต์

Access Control

ประเภททรัพยากร	รายการ	ดูรายละเอียด	สร้าง	อัปเดต	ลบ	ดำเนินการ
user	x	x
user_group	x	x	x	x	x
service_account	x	x	x		x
role	x	x	x		x
role_assignment	x		x
resource_group	x	x	x		x
permission	x

Governance

ประเภททรัพยากร	รายการ	ดูรายละเอียด	สร้าง	อัปเดต	ลบ	ดำเนินการ
policy	x	x	x	x	x
policy_set	x	x	x	x	x
policy_evaluation	x	x

Deployment Freeze

ประเภททรัพยากร	รายการ	ดูรายละเอียด	สร้าง	อัปเดต	ลบ	ดำเนินการ
freeze_window	x	x	x	x	x	toggle_status
global_freeze		x				manage

Service Overrides

ประเภททรัพยากร	รายการ	ดูรายละเอียด	สร้าง	อัปเดต	ลบ	ดำเนินการ
service_override	x	x	x	x	x

Settings

ประเภททรัพยากร	รายการ	ดูรายละเอียด	สร้าง	อัปเดต	ลบ	ดำเนินการ
setting	x

MCP Prompts

DevOps

Prompt	คำอธิบาย	พารามิเตอร์
build-deploy-app	เวิร์กโฟลว์ CI/CD แบบครบวงจร: สแกน git repo, สร้าง CI pipeline (build & push Docker image), ค้นหาหรือสร้าง K8s manifests, สร้าง CD pipeline, และ deploy — พร้อม auto-retry เมื่อ CI ล้มเหลว (สูงสุด 5 ครั้ง) และ CD ล้มเหลว (สูงสุด 3 ครั้งโดยได้รับอนุญาตจากผู้ใช้) เมื่อ retry หมดแล้ว จะให้ Harness UI deep links ไปยังทรัพยากรทั้งหมดที่สร้างขึ้นเพื่อการตรวจสอบด้วยตนเอง	repoUrl (จำเป็น), imageName (จำเป็น), projectId (ไม่บังคับ), namespace (ไม่บังคับ)
debug-pipeline-failure	วิเคราะห์ execution ที่ล้มเหลว: รับ execution ID, pipeline ID, หรือ Harness URL รับรายละเอียด stage/step, รายละเอียดความล้มเหลว, ข้อมูล delegate, และ logs ของ step ที่ล้มเหลวผ่าน harness_diagnose จากนั้นให้การวิเคราะห์สาเหตุต้นตอและคำแนะนำการแก้ไข ติดตามความล้มเหลวของ pipeline ที่เชื่อมโยงกันโดยอัตโนมัติ	executionId (ไม่บังคับ), projectId (ไม่บังคับ)
pipeline_summarizer	ดึงและสรุป logs ของทุก step จากการทำงานของ pipeline ใช้ harness_diagnose ร่วมกับ include_logs: true, include_all_step_logs: true เพื่อรับ log ของทุก step จากนั้นนำเสนอตารางพร้อม Step Name, Status, Duration, และ What Happened (สรุปจาก log) ไม่ข้าม step ใดๆ	executionId (ไม่บังคับ), projectId (ไม่บังคับ)
create-pipeline	สร้าง pipeline YAML ใหม่จากความต้องการในภาษาธรรมชาติ โดยตรวจสอบทรัพยากรที่มีอยู่เพื่อใช้เป็นบริบท	description (จำเป็น), projectId (ไม่บังคับ)
create-agent	สร้าง Harness AI agent แบบโต้ตอบ — ตรวจสอบ agents ที่มีอยู่ (ตรวจจับรูปแบบ agent.uses ปัจจุบันเทียบกับ agent.step.group.steps แบบเดิมเมื่ออัปเดต), รวบรวมความต้องการ, สร้าง agent spec ในรูปแบบที่เหมาะสม, ยืนยันกับผู้ใช้, จากนั้นสร้างหรืออัปเดตผ่าน harness_create/harness_update	agent_name (จำเป็น), task_description (จำเป็น), org_id (ไม่บังคับ), project_id (ไม่บังคับ)
onboard-service	แนะนำการเริ่มต้นใช้งานบริการใหม่พร้อม environments และ deployment pipeline	serviceName (จำเป็น), projectId (ไม่บังคับ)
dora-metrics-review	ตรวจสอบ DORA metrics (ความถี่ในการ deploy, อัตราความล้มเหลวของการเปลี่ยนแปลง, MTTR, lead time) พร้อมการจัดระดับ Elite/High/Medium/Low และคำแนะนำในการปรับปรุง	teamRefId (ไม่บังคับ), dateStart (ไม่บังคับ), dateEnd (ไม่บังคับ)
setup-gitops-application	แนะนำการเริ่มต้นใช้งาน GitOps application — ตรวจสอบ agent, cluster, repo, และสร้าง application	agentId (จำเป็น), projectId (ไม่บังคับ)
chaos-resilience-test	ออกแบบ chaos experiment เพื่อทดสอบความยืดหยุ่นของบริการด้วย fault injection, probes, และผลลัพธ์ที่คาดหวัง	serviceName (จำเป็น), projectId (ไม่บังคับ)
feature-flag-rollout	วางแผนและดำเนินการ progressive feature flag rollout ข้าม environments พร้อม safety gates	flagIdentifier (จำเป็น), projectId (ไม่บังคับ)
migrate-pipeline-to-template	วิเคราะห์ pipeline ที่มีอยู่และแยก templates ของ stage/step ที่นำกลับมาใช้ใหม่ได้	pipelineId (จำเป็น), projectId (ไม่บังคับ)
delegate-health-check	ตรวจสอบการเชื่อมต่อ delegate, สุขภาพ, สถานะ token, และแก้ไขปัญหาโครงสร้างพื้นฐาน	projectId (ไม่บังคับ)
developer-portal-scorecard	ตรวจสอบ IDP scorecards สำหรับบริการและระบุช่องว่างเพื่อปรับปรุงประสบการณ์นักพัฒนา	projectId (ไม่บังคับ)
pending-approvals	ค้นหา pipeline executions ที่รอการอนุมัติ, แสดงรายละเอียด, และเสนอให้อนุมัติหรือปฏิเสธ	projectId (ไม่บังคับ), orgId (ไม่บังคับ), pipelineId (ไม่บังคับ)

FinOps

Prompt	คำอธิบาย	พารามิเตอร์
optimize-costs	วิเคราะห์ข้อมูลต้นทุนคลาวด์, แสดงคำแนะนำและความผิดปกติ, จัดลำดับความสำคัญตามศักยภาพในการประหยัด	projectId (ไม่บังคับ)
cloud-cost-breakdown	เจาะลึกต้นทุนคลาวด์ตามบริการ, environment, หรือ cluster พร้อมการวิเคราะห์แนวโน้มและการตรวจจับความผิดปกติ	perspectiveId (ไม่บังคับ), projectId (ไม่บังคับ)
commitment-utilization-review	วิเคราะห์การใช้งาน reserved instance และ savings plan เพื่อค้นหาความสิ้นเปลืองและปรับปรุงข้อผูกพัน	projectId (ไม่บังคับ)
cost-anomaly-investigation	ตรวจสอบความผิดปกติของต้นทุน — หาสาเหตุต้นตอ, ทรัพยากรที่ได้รับผลกระทบ, และแนวทางแก้ไข	projectId (ไม่บังคับ)
rightsizing-recommendations	ตรวจสอบและจัดลำดับความสำคัญของคำแนะนำการปรับขนาด, เลือกสร้าง Jira หรือ ServiceNow tickets ได้	projectId (ไม่บังคับ), minSavings (ไม่บังคับ)

DevSecOps

Prompt	คำอธิบาย	พารามิเตอร์
security-review	ตรวจสอบปัญหาความปลอดภัยในทรัพยากร Harness ทั้งหมดและแนะนำแนวทางแก้ไขตามระดับความรุนแรง	projectId (ไม่บังคับ), severity (ไม่บังคับ, ค่าเริ่มต้น: critical,high)
vulnerability-triage	คัดแยกช่องโหว่ความปลอดภัยใน pipelines และ artifacts, จัดลำดับความสำคัญตามความรุนแรงและความสามารถในการโจมตี	projectId (ไม่บังคับ), severity (ไม่บังคับ)
sbom-compliance-check	ตรวจสอบ SBOM และสถานะการปฏิบัติตามข้อกำหนดสำหรับ artifacts — ความเสี่ยงด้านลิขสิทธิ์, การละเมิดนโยบาย, ช่องโหว่ของคอมโพเนนต์	artifactId (ไม่บังคับ), projectId (ไม่บังคับ)
supply-chain-audit	การตรวจสอบความปลอดภัยของซอฟต์แวร์ supply chain แบบครบวงจร — provenance, chain of custody, การปฏิบัติตามนโยบาย	projectId (ไม่บังคับ)
security-exemption-review	ตรวจสอบข้อยกเว้นความปลอดภัยที่รอดำเนินการและตัดสินใจอนุมัติหรือปฏิเสธเป็นชุด	projectId (ไม่บังคับ)
bulk-exemption-create	สร้างข้อยกเว้นความปลอดภัยที่มีเหตุผลสำหรับปัญหา STO หลายรายการพร้อมคำแนะนำขอบเขตและระยะเวลาที่ชัดเจน	projectId (จำเป็น), exemption_type (จำเป็น), reason (จำเป็น), ตัวกรองปัญหา (ไม่บังคับ)
access-control-audit	ตรวจสอบสิทธิ์ผู้ใช้, บัญชีที่มีสิทธิ์เกินความจำเป็น, และการกำหนดบทบาทเพื่อบังคับใช้หลักการสิทธิ์น้อยที่สุด	projectId (ไม่บังคับ), orgId (ไม่บังคับ)

Harness Code

Prompt	คำอธิบาย	พารามิเตอร์
code-review	ตรวจสอบ pull request — วิเคราะห์ diff, commits, checks และ comments เพื่อให้ข้อเสนอแนะเชิงโครงสร้างเกี่ยวกับบั๊ก ความปลอดภัย ประสิทธิภาพ และสไตล์	repoId (จำเป็น), prNumber (จำเป็น), projectId (ไม่บังคับ)
pr-summary	สร้างชื่อและคำอธิบาย PR โดยอัตโนมัติจากประวัติ commits และ diff ของ branch	repoId (จำเป็น), sourceBranch (จำเป็น), targetBranch (ไม่บังคับ, ค่าเริ่มต้น: main), projectId (ไม่บังคับ)
branch-cleanup	วิเคราะห์ branches ใน repository และแนะนำ branches ที่เก่าหรือถูก merge แล้วเพื่อลบ	repoId (จำเป็น), projectId (ไม่บังคับ)

ทรัพยากร MCP

Resource URI	คำอธิบาย	MIME Type
pipeline:///{pipelineId}	นิยาม Pipeline YAML	application/x-yaml
pipeline:///{orgId}/{projectId}/{pipelineId}	Pipeline YAML (พร้อมขอบเขตที่ชัดเจน)	application/x-yaml
executions:///recent	สรุปการทำงาน pipeline 10 รายการล่าสุด	application/json
schema:///pipeline	Harness pipeline JSON Schema	application/schema+json
schema:///template	Harness template JSON Schema	application/schema+json
schema:///trigger	Harness trigger JSON Schema	application/schema+json
schema:///pipeline_v1 (Alpha)	Harness V1 pipeline JSON Schema (รูปแบบ stages/steps แบบง่าย)	application/schema+json
schema:///agent-pipeline	Harness AI agent pipeline JSON Schema	application/schema+json
agent-docs:///legacy-format	เอกสารอ้างอิงรูปแบบ agent spec แบบเดิม (agent.step.group.steps / PLUGIN_TASK), อ่านโดย prompt create-agent เมื่ออัปเดต agent รูปแบบเดิมที่มีอยู่	text/markdown

การกรองชุดเครื่องมือ

โดยค่าเริ่มต้น 41 จาก 45 ชุดเครื่องมือถูกเปิดใช้งาน ชุดเครื่องมือสี่ชุดเป็นแบบเลือกใช้และถูกแยกออกจากค่าเริ่มต้น:

• ansible — Harness Ansible (inventories, playbooks, hosts, activity) เลือกใช้เนื่องจากเป็นแบบ project-scoped และเพิ่มแนวคิดที่ผู้ใช้หลายคนไม่ต้องการ
• autonomous_work — Development Harness (งานอัตโนมัติ) เลือกใช้; ดูคำอธิบายชุดเครื่องมือสำหรับขอบเขต
• observability-evaluations — กฎการประเมิน telemetry การผลิตตามกำหนดเวลา เลือกใช้เนื่องจากขึ้นอยู่กับ control plane การให้คะแนนที่ใช้งานอยู่
• registries-v3 — Harness Artifact Registry v3 (packages, versions, files, metadata, scans, firewall exceptions) เลือกใช้จนกว่าการเขียน v3 จะพร้อมใช้งาน เพื่อให้ agents ไม่ต้องแยกความแตกต่างระหว่าง v1 registries/artifacts และ v3 packages/versions

การเพิ่มชุดเครื่องมือด้วยคำนำหน้า +

ใช้คำนำหน้า + เพื่อรวมชุดเครื่องมือแบบเลือกใช้อย่างชัดเจนพร้อมกับค่าเริ่มต้นทั้งหมด:

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

การลบชุดเครื่องมือเริ่มต้น

ใช้คำนำหน้า - เพื่อแยกชุดเครื่องมือที่คุณไม่ต้องการ:

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

การรวม + และ -

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

รายการอนุญาตที่ชัดเจน

รายการที่คั่นด้วยเครื่องหมายจุลภาคอย่างชัดเจน (ไม่มีคำนำหน้า) แทนที่ค่าเริ่มต้นทั้งหมด เฉพาะชุดเครื่องมือที่ระบุเท่านั้นที่เปิดใช้งาน:

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

ชื่อชุดเครื่องมือที่พร้อมใช้งาน:

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

สถาปัตยกรรม

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

วิธีการทำงาน

1. เครื่องมือ (Tools) เป็นคำกริยาทั่วไป: harness_list, harness_get, ฯลฯ โดยรับพารามิเตอร์ resource_type เพื่อกำหนดเส้นทางไปยัง API endpoint ที่ถูกต้อง
2. Registry จะแมปแต่ละ resource_type ไปยัง ResourceDefinition ซึ่งเป็นโครงสร้างข้อมูลแบบ declarative ที่ระบุ HTTP method, URL path, การแมปพารามิเตอร์ path/query และตรรกะการแยกข้อมูลจาก response
3. Dispatch จะแก้ไข resource definition สร้าง HTTP request (การแทนที่ path, query params, การฉีด account/org/project ที่คำนึงถึง resource_scope) เรียกใช้ Harness API ผ่าน HarnessClient และแยกข้อมูล response ที่เกี่ยวข้อง
4. การกรองชุดเครื่องมือ (Toolset filtering) (HARNESS_TOOLSETS) ควบคุมว่า resource definitions ใดจะถูกโหลดเข้าสู่ registry เมื่อเริ่มต้น
5. ผลลัพธ์แบบมีโครงสร้าง (Structured output) ถูกประกาศด้วย MCP outputSchema; harness_list จะแปลง arrays และ list wrappers ทั่วไปให้เป็น structuredContent รูปทรง object สำหรับไคลเอนต์ที่เข้มงวด
6. Deep links จะถูกผนวกเข้ากับ response โดยอัตโนมัติ โดยให้ URL ของ Harness UI โดยตรงสำหรับทุก resource
7. โหมดกระชับ (Compact mode) จะตัด metadata ที่ละเอียดออกจากผลลัพธ์รายการ โดยคงไว้เฉพาะฟิลด์ที่ใช้งานได้จริง (identity, status, type, timestamps, deep links) เพื่อลดการใช้ token

การเพิ่ม Resource Type ใหม่

สร้างไฟล์ใหม่ใน src/registry/toolsets/ หรือเพิ่ม resource ลงในชุดเครื่องมือที่มีอยู่:

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

จากนั้น import ใน src/registry/index.ts และเพิ่มลงในอาร์เรย์ ALL_TOOLSETS ไม่จำเป็นต้องแก้ไขไฟล์เครื่องมือใดๆ

การพัฒนา

# Build
pnpm build

# Watch mode
pnpm dev

# Type check
pnpm typecheck

# Run tests
pnpm test

# Watch tests
pnpm test:watch

# Interactive MCP Inspector
pnpm inspect

# Refresh generated README counts from the built registry
pnpm docs:generate

# Verify README counts and clone instructions are current
pnpm docs:check

# Sync and verify JSON Schemas used by harness_schema
pnpm sync-schemas
pnpm check-schema-coverage

โครงสร้างโปรเจกต์

src/
  index.ts                          # Entrypoint, transport setup
  config.ts                         # Env var validation (Zod)
  client/
    harness-client.ts               # HTTP client (auth, retry, rate limiting)
    types.ts                        # Shared API types
  registry/
    index.ts                        # Registry class + dispatch logic
    types.ts                        # ResourceDefinition, ToolsetDefinition, etc.
    toolsets/                        # One file per toolset (declarative data)
      platform.ts
      pipelines.ts
      services.ts
      ccm.ts
      access-control.ts
      ...
  tools/                            # 11 generic MCP tools
    harness-list.ts
    harness-get.ts
    harness-create.ts
    harness-update.ts
    harness-delete.ts
    harness-execute.ts
    harness-search.ts
    harness-diagnose.ts
    harness-describe.ts
    harness-status.ts
    harness-schema.ts

  resources/                        # MCP resource providers
    pipeline-yaml.ts
    execution-summary.ts
  prompts/                          # MCP prompt templates
    build-deploy-app.ts             # DevOps: end-to-end build & deploy workflow
    debug-pipeline.ts               # DevOps: debug failed executions
    create-pipeline.ts              # DevOps: generate pipeline from requirements
    onboard-service.ts              # DevOps: onboard new service
    dora-metrics.ts                 # DevOps: DORA metrics review
    setup-gitops.ts                 # DevOps: GitOps application setup
    chaos-resilience.ts             # DevOps: chaos experiment design
    feature-flag-rollout.ts         # DevOps: progressive flag rollout
    migrate-to-template.ts          # DevOps: extract templates from pipeline
    delegate-health.ts              # DevOps: delegate health check
    developer-scorecard.ts          # DevOps: IDP scorecard review
    optimize-costs.ts               # FinOps: cost optimization
    cloud-cost-breakdown.ts         # FinOps: cost deep-dive
    commitment-utilization.ts       # FinOps: RI/savings plan analysis
    cost-anomaly.ts                 # FinOps: anomaly investigation
    rightsizing.ts                  # FinOps: rightsizing recommendations
    security-review.ts              # DevSecOps: security issue review
    vulnerability-triage.ts         # DevSecOps: vulnerability triage
    sbom-compliance.ts              # DevSecOps: SBOM compliance audit
    supply-chain-audit.ts           # DevSecOps: supply chain audit
    exemption-review.ts             # DevSecOps: exemption approval
    access-control-audit.ts         # DevSecOps: access control audit
    code-review.ts                  # Harness Code: PR code review
    pr-summary.ts                   # Harness Code: auto-generate PR summary
    branch-cleanup.ts               # Harness Code: stale branch cleanup
    pending-approvals.ts            # Approvals: find and act on pending approvals
  utils/
    cli.ts                          # CLI arg parsing (transport, port)
    errors.ts                       # Error normalization
    logger.ts                       # stderr-only logger
    progress.ts                     # MCP progress & logging notifications
    rate-limiter.ts                 # Client-side rate limiting
    deep-links.ts                   # Harness UI deep link builder
    response-formatter.ts           # Consistent MCP response formatting
    compact.ts                      # Compact list output for token efficiency
tests/
  config.test.ts                    # Config schema validation tests
  utils/
    response-formatter.test.ts
    deep-links.test.ts
    errors.test.ts
  registry/
    registry.test.ts                # Registry loading, filtering, dispatch tests

การขอความยืนยัน (Elicitation)

เครื่องมือเขียน (harness_create, harness_update, harness_delete, harness_execute) ใช้ MCP elicitation เพื่อแจ้งให้ผู้ใช้ยืนยันเมื่อการดำเนินการมีความเสี่ยงที่ต้องยืนยัน — เฉพาะการดำเนินการ medium_write, high_write และ destructive เท่านั้น การสร้าง/อัปเดต/อ่านที่มีความเสี่ยงต่ำ (เช่น pipeline.create, pipeline.update, hql_query.run) จะดำเนินการอย่างเงียบๆ โดยไม่มีการแจ้งเตือน เมื่อมีการแสดงการแจ้งเตือน ผู้ใช้จะเห็นสิ่งที่กำลังจะเกิดขึ้นและยอมรับหรือปฏิเสธ ซึ่งเป็นการให้การอนุมัติแบบ human-in-the-loop จริงสำหรับการดำเนินการที่เปลี่ยนแปลงหรือรันสิ่งต่างๆ

วิธีการทำงาน:

1. LLM เรียกใช้เครื่องมือเขียนที่มีความเสี่ยง medium_write+ (เช่น harness_delete, harness_execute pipeline.run) การสร้าง/อัปเดต/อ่านที่มีความเสี่ยงต่ำจะไม่แสดงการแจ้งเตือน
2. เซิร์ฟเวอร์ส่งคำขอ elicitation ไปยังไคลเอนต์พร้อมสรุปการดำเนินการและช่องทำเครื่องหมาย confirm (เลือกไว้เป็นค่าเริ่มต้น)
3. ผู้ใช้เห็นรายละเอียดและคลิก ยอมรับ (Accept) (โดยที่ confirm ถูกเลือก) หรือ ปฏิเสธ / ยกเลิก (Decline / Cancel)
4. หากยอมรับโดยที่ confirm: true ถูกเลือก การดำเนินการจะดำเนินต่อไป หากยอมรับโดยที่ confirm ไม่ถูกเลือก ปฏิเสธ หรือยกเลิก การดำเนินการจะถูกบล็อกและแจ้งให้ LLM ทราบ (การปฏิเสธอย่างชัดเจนถือเป็น เด็ดขาด และไม่สามารถข้ามได้ด้วย confirm: true ในการเรียกใช้เครื่องมือ)

การรองรับไคลเอนต์:

ไคลเอนต์	การรองรับ Elicitation
Cursor	ใช่
VS Code (Copilot)	ใช่
Claude Desktop	ยังไม่รองรับ
Devin Desktop	ยังไม่รองรับ
MCP Inspector	ใช่

พฤติกรรมของ elicitation แตกต่างกันตามความเสี่ยงของการดำเนินการเมื่อไคลเอนต์ไม่รองรับ:

ระดับความเสี่ยง	ไคลเอนต์รองรับ elicitation	ส่ง confirm: true	พฤติกรรม
read, low_write	เท่าใดก็ได้	เท่าใดก็ได้	ดำเนินการอย่างเงียบๆ — ไม่มีการแสดงการแจ้งเตือน (confirm ไม่มีผลในระดับความเสี่ยงนี้)
medium_write, high_write, destructive	ใช่	เท่าใดก็ได้	แจ้งเตือนผู้ใช้ ดำเนินการต่อเมื่อผู้ใช้ยอมรับ โดยที่ confirm: true ถูกเลือก (ค่าเริ่มต้นของ schema) การปฏิเสธอย่างชัดเจน การยกเลิก หรือการยอมรับโดยที่ confirm: false (ผู้ใช้ยกเลิกการเลือกช่อง) ถือเป็น เด็ดขาด และไม่ถูกข้ามด้วย confirm: true ในการเรียกใช้เครื่องมือ การยอมรับที่ไม่มีฟิลด์ confirm ถือว่าไคลเอนต์ไม่สามารถแสดงการแจ้งเตือนที่ใช้งานได้ — สามารถกู้คืนได้โดยลองใหม่ด้วย confirm: true
medium_write, high_write, destructive	ไม่	ไม่	บล็อก (ส่งคืนข้อผิดพลาดพร้อมคำแนะนำให้ลองใหม่ด้วย confirm: true)
medium_write, high_write, destructive	ไม่	ใช่	ดำเนินการต่อ (เลือกเข้าร่วมอย่างชัดเจนสำหรับระบบอัตโนมัติแบบไม่โต้ตอบ)
เท่าใดก็ได้ (ที่หรือต่ำกว่า HARNESS_AUTO_APPROVE_RISK)	เท่าใดก็ได้	เท่าใดก็ได้	อนุมัติอัตโนมัติโดยไม่ต้องแจ้งเตือน

หาก elicitInput ล้มเหลวในขณะรันไทม์ (ข้อผิดพลาดการเชื่อมต่อ วิธีการที่ไม่รองรับ) สำหรับการดำเนินการ medium_write+ การเรียกใช้จะถูกบล็อกเว้นแต่ผู้เรียกส่ง confirm: true confirm: true ถือเป็นตัวสำรองเมื่อไคลเอนต์ไม่สามารถแสดงการแจ้งเตือนหรือส่งคืนการยอมรับที่ผิดปกติ ({action: "accept"} โดยไม่มีฟิลด์ยืนยัน) แต่จะ ไม่ แทนที่การปฏิเสธ/ยกเลิกอย่างชัดเจนจากไคลเอนต์ที่ทำ handshake elicitation เสร็จสมบูรณ์

โหมดอัตโนมัติ (Autonomous Mode)

โหมดอัตโนมัติ หมายความว่าเซิร์ฟเวอร์ดำเนินการทั้งหมด — รวมถึงการเขียนและการดำเนินการที่ทำลายล้าง — โดยไม่ต้องแจ้งให้ยืนยัน เปิดใช้งานโดยการตั้งค่า:

HARNESS_AUTO_APPROVE_RISK=all

นี่คือเพดานระดับการปรับใช้: เมื่อตั้งค่าแล้ว แต่ละเซสชันไม่สามารถเพิ่มระดับเกินกว่านี้ได้ (แม้ว่าจะเลือกเกณฑ์ที่เข้มงวดกว่าต่อเซสชันได้ผ่าน header x-harness-auto-approve-risk)

หรือในการกำหนดค่าไคลเอนต์ MCP ของคุณ:

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

อัตโนมัติบางส่วน: คุณยังสามารถอนุมัติอัตโนมัติเฉพาะระดับความเสี่ยงที่กำหนดในขณะที่ยังแจ้งเตือนสำหรับการดำเนินการที่มีความเสี่ยงสูงกว่า:

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

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

ค่า	สิ่งที่อนุมัติอัตโนมัติ
none (ค่าเริ่มต้น)	ไม่มีอะไร — ไม่มีเกณฑ์การอนุมัติอัตโนมัติ
low_write	การอ่าน + การเขียนความเสี่ยงต่ำ
medium_write	การอ่าน + การเขียนความเสี่ยงต่ำและปานกลาง
high_write	การอ่าน + การเขียนความเสี่ยงต่ำ ปานกลาง และสูง
all	ทุกอย่าง รวมถึงการดำเนินการที่ทำลายล้าง

คำเตือนโหมดอัตโนมัติ: HARNESS_AUTO_APPROVE_RISK=all ข้ามการยืนยันสำหรับ ทุก การดำเนินการ รวมถึง harness_delete ใช้ด้วยความระมัดระวังและพิจารณาจับคู่กับ HARNESS_TOOLSETS เพื่อจำกัดประเภท resource ที่พร้อมใช้งาน

หมายเหตุการย้ายระบบ: HARNESS_SKIP_ELICITATION=true ยังคงรองรับและแมปไปยัง HARNESS_AUTO_APPROVE_RISK=all มีการบันทึกคำเตือนการเลิกใช้งานไปยัง stderr หากตั้งค่าทั้งสอง HARNESS_AUTO_APPROVE_RISK จะมีความสำคัญกว่า

ความปลอดภัย

• ความลับจะไม่ถูกเปิดเผย ประเภท resource secret ส่งคืนเฉพาะ metadata (ชื่อ ประเภท ขอบเขต) — ค่าความลับจะไม่รวมอยู่ใน response ใดๆ
• การดำเนินการที่ต้องยืนยันใช้ elicitation เมื่อพร้อมใช้งาน เมื่อการดำเนินการเขียนหรือ execute มีความเสี่ยง medium_write, high_write หรือ destructive, harness_create, harness_update, harness_delete และ harness_execute จะพยายามใช้ MCP elicitation ก่อนดำเนินการ (ดู Elicitation) การดำเนินการความเสี่ยงต่ำ (read, low_write — เช่น pipeline.create, pipeline.update, hql_query.run) ดำเนินการอย่างเงียบๆ โดยไม่มีการแจ้งเตือน
• ความเสี่ยงปานกลางขึ้นไปจะปิดเมื่อล้มเหลว (fail closed) หากไม่สามารถยืนยันสำหรับการดำเนินการ medium_write, high_write หรือ destructive การดำเนินการเหล่านั้นจะถูกบล็อกแทนที่จะดำเนินการโดยไม่รู้ แทนที่ด้วย HARNESS_AUTO_APPROVE_RISK สำหรับเวิร์กโฟลว์อัตโนมัติ
• CORS จำกัดเฉพาะ same-origin การขนส่ง HTTP อนุญาตเฉพาะคำขอ same-origin เพื่อป้องกันการโจมตี CSRF จากเว็บไซต์ที่เป็นอันตรายที่กำหนดเป้าหมาย MCP server บน localhost
• การจำกัดอัตรา HTTP การขนส่ง HTTP บังคับ 60 คำขอต่อนาทีต่อ IP เพื่อป้องกันการส่งคำขอท่วม
• การจำกัดอัตรา API ไคลเอนต์ Harness API บังคับขีดจำกัด 10 คำขอ/วินาทีเพื่อหลีกเลี่ยงการชนขีดจำกัดอัตราของ upstream
• บังคับขอบเขตการแบ่งหน้า คำขอรายการถูกจำกัดที่ 10,000 รายการทั้งหมดและ 100 ต่อหน้าเพื่อป้องกันหน่วยความจำหมด
• ลองใหม่พร้อม backoff ความล้มเหลวชั่วคราว (HTTP 429, 5xx) จะถูกลองใหม่ด้วย exponential backoff และ jitter
• ผูกกับ Localhost การขนส่ง HTTP ผูกกับ 127.0.0.1 โดยค่าเริ่มต้น — ไม่สามารถเข้าถึงได้จากเครือข่าย
• ไม่มีการบันทึก stdout บันทึกทั้งหมดไปที่ stderr เพื่อหลีกเลี่ยงการทำให้การขนส่ง stdio JSON-RPC เสียหาย

ทักษะเสริม (Complementary Skills)

Harness MCP server ทำงานร่วมกับ Harness Skills ได้ดี — ชุดทักษะ Claude Code ที่พร้อมใช้งาน (คำสั่ง slash) ที่ออกแบบมาสำหรับเวิร์กโฟลว์ Harness ทั่วไป ติดตั้งพร้อมกับ MCP server นี้เพื่อรับระบบอัตโนมัติระดับสูง เช่น /deploy, /rollback, /triage และอื่นๆ โดยไม่ต้องเขียนพรอมต์ที่กำหนดเอง

การแก้ไขปัญหาและข้อผิดพลาดทั่วไป

อาการ	สาเหตุที่เป็นไปได้	สิ่งที่ควรทำ
HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...	คีย์ API ไม่อยู่ในรูปแบบที่รองรับระดับบัญชี (pat.<accountId>... หรือ sat.<accountId>...) จึงไม่สามารถอนุมานรหัสบัญชีได้	ตั้งค่า HARNESS_ACCOUNT_ID อย่างชัดเจน
Unknown transport: "..." เมื่อเริ่มต้น	อาร์กิวเมนต์ transport ของ CLI ไม่รองรับ	ใช้เฉพาะ stdio หรือ http เท่านั้น
Invalid HARNESS_TOOLSETS: ... เมื่อเริ่มต้น	ชื่อชุดเครื่องมือหนึ่งรายการขึ้นไปไม่เป็นที่รู้จัก	ใช้เฉพาะชื่อจาก การกรองชุดเครื่องมือ (ตรงกันทุกตัวอักษร)
HTTP mcp-session-id header is required...	คำขอเซสชันถูกส่งโดยไม่มีส่วนหัวเซสชัน	ส่ง initialize ก่อน จากนั้นรวม mcp-session-id ใน POST/GET/DELETE /mcp
HTTP Session not found...	เซสชันหมดอายุหลังจากไม่มีการใช้งาน MCP_SESSION_TTL_MS มิลลิวินาที หรือถูกปิดไปแล้ว	รัน initialize ใหม่เพื่อสร้างเซสชันใหม่ จากนั้นลองใหม่ด้วยส่วนหัวใหม่
HTTP 405 Method Not Allowed บน /mcp	เมธอดไม่รองรับสำหรับปลายทาง MCP	ใช้เฉพาะ POST, GET, DELETE, หรือ OPTIONS เท่านั้น
HTTP Invalid request	เนื้อหา JSON ไม่ถูกต้อง หรือขนาดคำขอเกิน HARNESS_MAX_BODY_SIZE_MB	ตรวจสอบขนาด/รูปแบบของเพย์โหลด JSON; เพิ่ม HARNESS_MAX_BODY_SIZE_MB หากจำเป็น
Unknown resource_type "..." จากเครื่องมือ	ประเภททรัพยากรสะกดผิด หรือถูกกรองออกผ่าน HARNESS_TOOLSETS	เรียก harness_describe (พร้อม search_term ที่ไม่บังคับ) เพื่อค้นหาประเภทที่ถูกต้อง
Missing required field "... for path parameter ..."	การเรียกที่ขอบเขตโปรเจกต์/องค์กรขาดตัวระบุ	ตั้งค่า HARNESS_ORG/HARNESS_PROJECT หรือส่ง org_id/project_id ในการเรียกเครื่องมือแต่ละครั้ง
resource_scope "org" requires org_id... หรือ resource_scope "project" requires project_id...	ทรัพยากรหลายขอบเขตถูกบังคับให้เป็นขอบเขตองค์กร/โปรเจกต์โดยไม่มีตัวระบุเพียงพอ	ส่ง org_id/project_id ที่ขาดหายไป กำหนดค่า HARNESS_ORG/HARNESS_PROJECT หรือใช้ resource_scope: "account" เมื่อรองรับ
Read-only mode is enabled ... operations are not allowed	HARNESS_READ_ONLY=true บล็อกการสร้าง/อัปเดต/ลบ/ดำเนินการ	ตั้งค่า HARNESS_READ_ONLY=false หากต้องการดำเนินการเขียน
การรันไปป์ไลน์ล้มเหลวก่อนตรวจสอบด้วยอินพุตที่จำเป็นซึ่งยังไม่ได้รับการแก้ไข	inputs ที่ให้ไว้ไม่ครอบคลุมตัวยึดตำแหน่งรันไทม์ที่จำเป็น	ดึง runtime_input_template, จัดหาคีย์แบบง่ายที่ขาดหายไป หรือใช้ input_set_ids สำหรับอินพุตเชิงโครงสร้าง
ชวเลข CI ของไปป์ไลน์ (branch, tag, pr_number, commit_sha) ไม่ถูกนำไปใช้	มีการให้ inputs.build แล้ว จึงข้ามการขยายชวเลขโดยเจตนา	ลบ inputs.build เพื่อใช้การขยายชวเลข หรือเก็บโครงสร้าง build แบบเต็มที่ชัดเจน
การรันไปป์ไลน์โหลดรีวิชัน YAML ผิด	คำจำกัดความของไปป์ไลน์ถูกเก็บใน Git และการรันไม่ได้ระบุสาขาไปป์ไลน์ที่ต้องการ	ส่ง params.pipeline_branch ในแอ็กชัน run; ซึ่งแมปกับ Harness branch
wait: true ส่งคืน _wait.error	ทริกเกอร์ไปป์ไลน์สำเร็จ แต่การโพลฝั่งเซิร์ฟเวอร์ล้มเหลว	ตรวจสอบ execution_id อีกครั้งด้วย harness_get(resource_type="execution", ...) ก่อนตัดสินใจรันใหม่
wait: true ส่งคืน execution_timed_out: true	การดำเนินการไปไม่ถึงสถานะสิ้นสุดก่อน wait_timeout_seconds	ใช้ execution_id ที่ส่งคืนเพื่อตรวจสอบสถานะอีกครั้ง; รอสถานะสิ้นสุดก่อนรัน harness_diagnose
บันทึกการดำเนินการว่างเปล่าหรือการดาวน์โหลด blob ส่งคืน 403	URL blob บันทึกที่โฮสต์โดย Harness ต้องใช้เส้นทางไคลเอ็นต์/การรับรองความถูกต้องของ Harness ที่กำหนดค่าไว้ โดยเฉพาะสำหรับโฮสต์ภายในหรือที่จัดการเอง	ให้ HARNESS_BASE_URL ชี้ไปที่โฮสต์ Harness เป้าหมาย และใช้ harness_get(resource_type="execution_log", ...) หรือ harness_diagnose(..., include_logs=true) แทนการเลี่ยงไคลเอ็นต์ MCP
Operation declined by user / Operation cancelled by user	ผู้ใช้ปฏิเสธหรือยกเลิกกล่องโต้ตอบยืนยันการขอข้อมูล — มีอำนาจตัดสินใจ	ตรวจสอบรายละเอียดการดำเนินการกับผู้ใช้; confirm: true ไม่ เลี่ยงการปฏิเสธอย่างชัดเจน ผู้ใช้ต้องยอมรับพรอมต์
Operation blocked: the client could not surface a usable confirmation prompt	ไคลเอ็นต์ขาดการรองรับการขอข้อมูล, elicitInput ล้มเหลว หรือส่งคืนการยอมรับที่ผิดปกติ	ลองใหม่ด้วย confirm: true สำหรับระบบอัตโนมัติแบบไม่โต้ตอบ หรือใช้ไคลเอ็นต์ที่รองรับการขอข้อมูล
body.template_yaml (or body.yaml) is required สำหรับการสร้าง/อัปเดตเทมเพลต	API เทมเพลตคาดหวังเพย์โหลด YAML เต็มรูปแบบ	ให้สตริง template_yaml เต็มรูปแบบใน body; สำหรับการลบ ส่ง version_label เพื่อลบหนึ่งเวอร์ชัน (ละเว้นเพื่อลบทุกเวอร์ชัน)
HARNESS_BASE_URL must use HTTPS เมื่อเริ่มต้น	HARNESS_BASE_URL ถูกตั้งค่าเป็น URL HTTP	ใช้ HTTPS หรือตั้งค่า HARNESS_ALLOW_HTTP=true สำหรับการพัฒนาท้องถิ่น

ใบอนุญาต

MIT