Harness

Harness MCP सर्वर 2.0

एक MCP (मॉडल कॉन्टेक्स्ट प्रोटोकॉल) सर्वर जो AI एजेंटों को 11 समेकित टूल और 255 संसाधन प्रकारों के माध्यम से Harness.io प्लेटफ़ॉर्म तक पूर्ण पहुंच प्रदान करता है।

इस MCP सर्वर का उपयोग क्यों करें

अधिकांश MCP सर्वर प्रति API एंडपॉइंट एक टूल मैप करते हैं। Harness जितने व्यापक प्लेटफ़ॉर्म के लिए, इसका मतलब है 240+ टूल — और संख्या बढ़ने पर LLM टूल चयन में खराब हो जाते हैं। कॉन्टेक्स्ट विंडो स्कीमा से भर जाती हैं, और हर नए एंडपॉइंट का मतलब नया कोड होता है।

यह सर्वर अलग तरीके से बनाया गया है:

• 11 टूल, 255 संसाधन प्रकार। एक रजिस्ट्री-आधारित डिस्पैच सिस्टम harness_list, harness_get, harness_create, आदि को किसी भी Harness संसाधन — पाइपलाइन, सेवाएं, वातावरण, संगठन, प्रोजेक्ट, फीचर फ्लैग, लागत डेटा, और अधिक — तक रूट करता है। LLM सैकड़ों के बजाय 11 टूल में से चुनता है।
• पूर्ण प्लेटफ़ॉर्म कवरेज। CI/CD, GitOps, फीचर फ्लैग, क्लाउड लागत प्रबंधन, सुरक्षा परीक्षण, कैओस इंजीनियरिंग, डेटाबेस DevOps, आंतरिक डेवलपर पोर्टल, सॉफ़्टवेयर आपूर्ति श्रृंखला, इंफ्रास्ट्रक्चर कोड प्रबंधन, रिलीज़ प्रबंधन, शासन, सेवा ओवरराइड, ज्ञान ग्राफ, और अधिक को कवर करने वाले 41 डिफ़ॉल्ट टूलसेट। आवश्यकता पड़ने पर ऑप्ट-इन Ansible और ऑब्ज़र्वेबिलिटी-मूल्यांकन कवरेज उपलब्ध है।
• बॉक्स से बाहर मल्टी-प्रोजेक्ट वर्कफ़्लो। एजेंट संगठनों और प्रोजेक्ट्स को गतिशील रूप से खोजते हैं — कोई हार्डकोडेड env vars आवश्यक नहीं। "सभी प्रोजेक्ट्स में विफल निष्पादन दिखाएं" पूछें और एजेंट पूर्ण खाता पदानुक्रम को नेविगेट कर सकता है।
• 35 प्रॉम्प्ट टेम्पलेट। सामान्य वर्कफ़्लो के लिए पूर्व-निर्मित प्रॉम्प्ट: एंड-टू-एंड ऐप्स बनाएं और तैनात करें, विफल पाइपलाइनों को डीबग करें, DORA मेट्रिक्स की समीक्षा करें, कमजोरियों को ट्रायेज करें, क्लाउड लागत अनुकूलित करें, एक्सेस नियंत्रण ऑडिट करें, फीचर फ्लैग रोलआउट की योजना बनाएं, पुल अनुरोधों की समीक्षा करें, लंबित पाइपलाइनों को अनुमोदित करें, और अधिक।
• हर जगह काम करता है। स्थानीय क्लाइंट (Claude Desktop, Cursor, Devin Desktop) के लिए Stdio ट्रांसपोर्ट, रिमोट/साझा तैनाती के लिए HTTP ट्रांसपोर्ट, Docker और Kubernetes के लिए तैयार।
• शून्य-कॉन्फ़िगरेशन शुरुआत। बस एक Harness API कुंजी प्रदान करें। खाता ID स्वचालित रूप से PAT और SAT टोकन से निकाला जाता है, org/project डिफ़ॉल्ट वैकल्पिक हैं, और टूलसेट फ़िल्टरिंग आपको केवल वही उजागर करने देती है जो आपको चाहिए।
• डिज़ाइन द्वारा विस्तार योग्य। एक नया Harness संसाधन जोड़ने का मतलब है एक घोषणात्मक डेटा फ़ाइल जोड़ना — कोई नया टूल पंजीकरण नहीं, कोई स्कीमा परिवर्तन नहीं, कोई प्रॉम्प्ट अपडेट नहीं।

पूर्वापेक्षाएँ

सर्वर स्थापित करने या चलाने से पहले, आपको एक Harness API कुंजी चाहिए:

1. अपने Harness खाते में लॉग इन करें
2. मेरी प्रोफ़ाइल → API कुंजियाँ → + नई API कुंजी पर जाएं
3. API कुंजी के अंतर्गत एक नया टोकन बनाएं — यह <prefix>.<accountId>.<tokenId>.<secret> प्रारूप में एक PAT या SAT उत्पन्न करता है
4. टोकन को कहीं सुरक्षित सहेजें — आपको अगले चरण में इसकी आवश्यकता होगी

विस्तृत निर्देशों के लिए, Harness API क्विकस्टार्ट देखें।

त्वरित प्रारंभ

विकल्प 0: होस्टेड Harness MCP

यदि आपके Harness खाते में होस्टेड MCP सेवा सक्षम है, तो रिमोट MCP सर्वर का समर्थन करने वाले क्लाइंट सर्वर को स्थानीय रूप से चलाने के बजाय सीधे प्रबंधित एंडपॉइंट से कनेक्ट हो सकते हैं।

महत्वपूर्ण: होस्टेड MCP सेवा Harness प्लेटफ़ॉर्म OAuth का उपयोग करती है, HARNESS_API_KEY नहीं। एंडपॉइंट का उपयोग करने से पहले इसे Harness सपोर्ट द्वारा प्रति खाता सक्षम/कॉन्फ़िगर भी किया जाना चाहिए।

कॉन्फ़िगरेशन उदाहरणों के लिए होस्टेड Harness MCP देखें।

विकल्प 1: npx (अनुशंसित)

कोई स्थापना आवश्यक नहीं — बस इसे चलाएं:

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

या अपने AI क्लाइंट में API कुंजी कॉन्फ़िगर करें (नीचे क्लाइंट कॉन्फ़िगरेशन देखें)।

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

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

नोट: खाता ID स्वचालित रूप से PAT और SAT टोकन (pat.<accountId>... या sat.<accountId>...) से निकाला जाता है, इसलिए HARNESS_ACCOUNT_ID केवल एम्बेडेड खाता खंड के बिना API कुंजियों के लिए आवश्यक है।

विकल्प 2: वैश्विक स्थापना

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

विकल्प 3: स्रोत से निर्माण

विकास या अनुकूलन के लिए:

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

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

Anthropic MCP निर्देशिका बंडल

MCPB बंडल मैनिफेस्ट [mcp-directory/](mcp-directory/) में रहता है, और 512×512 बंडल आइकन रिपॉजिटरी रूट में [icon.png](icon.png) पर ट्रैक किया जाता है। पैकेज्ड संग्रह में रूट-स्तरीय manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json, और उत्पादन node_modules/ शामिल हैं।

संग्रह को छोटा रखने के लिए, स्टेजिंग निर्देशिका से MCPB पैकेज बनाएं:

pnpm prepare:mcpb

स्टेजिंग निर्देशिका dist/mcpb/ में npm के फ्लैट लेआउट का उपयोग करके npm-shrinkwrap.json से उत्पादन निर्भरताएं स्थापित करके लिखी जाती है। पिन किया गया आधिकारिक MCPB CLI इसे मान्य करता है और dist/harness-mcp-server-<version>.mcpb बनाता है।

v*.*.* से मेल खाने वाले संस्करण टैग उस बंडल को स्वचालित रूप से संबंधित GitHub रिलीज़ में प्रकाशित करते हैं। npm को फिर से प्रकाशित किए बिना मौजूदा रिलीज़ को बैकफिल करने के लिए, Release वर्कफ़्लो को उसके release_tag इनपुट के साथ मैन्युअल रूप से चलाएं (उदाहरण के लिए, v3.2.20)। वर्कफ़्लो उस सटीक टैग को चेक आउट करता है और बनाता है, फिर केवल उसके संस्करणित MCPB एसेट को प्रतिस्थापित करता है।

CLI उपयोग

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

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

यदि निर्दिष्ट नहीं है तो ट्रांसपोर्ट डिफ़ॉल्ट रूप से stdio होता है। रिमोट/साझा तैनाती के लिए http का उपयोग करें।

HTTP ट्रांसपोर्ट

HTTP मोड में चलते समय, सर्वर उजागर करता है:

एंडपॉइंट	विधि	विवरण
/mcp	POST	MCP JSON-RPC एंडपॉइंट (initialize + session अनुरोध)
/mcp	GET	सर्वर-आरंभित संदेशों के लिए SSE स्ट्रीम (प्रगति, elicitation)
/mcp	DELETE	एक सक्रिय MCP सत्र समाप्त करें
/mcp	OPTIONS	CORS प्रीफ्लाइट
/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	डिफ़ॉल्ट /mcp संसाधन के लिए पथ-जागरूक RFC 9728 मेटाडेटा

HTTP ट्रांसपोर्ट सत्र-आधारित मोड में चलता है। initialize पर एक नया MCP सत्र बनाया जाता है, सर्वर एक mcp-session-id हेडर लौटाता है, और उस सत्र के लिए बाद के अनुरोधों में समान हेडर शामिल होना चाहिए।

HTTP मोड में परिचालन बाधाएं:

• साझा या रिमोट से पहुंच योग्य एकल-उपयोगकर्ता और बहु-उपयोगकर्ता तैनाती के लिए HARNESS_MCP_AUTH_TOKEN सेट करें। सेट होने पर, /mcp पर हर POST, GET, और DELETE अनुरोध में Authorization: Bearer <token> शामिल होना चाहिए।
• OAuth मोड HARNESS_MCP_AUTH_TOKEN के बजाय HarnessID एक्सेस टोकन स्वीकार करता है और बिना प्रमाणीकरण ऑप्ट-आउट के गैर-लूपबैक पते से बाइंड हो सकता है।
• गैर-लूपबैक एकल-उपयोगकर्ता और बहु-उपयोगकर्ता बाइंड को डिफ़ॉल्ट रूप से HARNESS_MCP_AUTH_TOKEN की आवश्यकता होती है। फिर भी गैर-लूपबैक इंटरफ़ेस पर बिना प्रमाणीकरण चलाने के लिए, HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true स्पष्ट रूप से सेट करें।
• POST /mcp बिना mcp-session-id के एक initialize अनुरोध होना चाहिए।
• मौजूदा सत्रों के लिए POST /mcp, GET /mcp, और DELETE /mcp को mcp-session-id हेडर की आवश्यकता होती है।
• GET /mcp SSE सूचनाओं (प्रगति अपडेट और elicitation प्रॉम्प्ट) के लिए उपयोग किया जाता है।
• निष्क्रिय सत्र MCP_SESSION_TTL_MS मिलीसेकंड के बाद समाप्त हो जाते हैं जब कोई अनुरोध या SSE स्ट्रीम सक्रिय नहीं होती (डिफ़ॉल्ट 1800000, या 30 मिनट)।
• GET /health एकमात्र गैर-MCP एंडपॉइंट है।
• अनुरोध निकाय आकार HARNESS_MAX_BODY_SIZE_MB द्वारा सीमित है (डिफ़ॉल्ट 10 MB)।
• उस HTTP सत्र के लिए V0 या V1 पाइपलाइन संसाधनों का चयन करने के लिए initialize अनुरोध पर x-harness-pipeline-version: 0 या 1 सेट करें।
• प्रति-सत्र सख्त स्वतः-अनुमोदन सीमा चुनने के लिए initialize अनुरोध पर x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all सेट करें। सर्वर इस मान को तैनाती-स्तरीय HARNESS_AUTO_APPROVE_RISK पर सीमित करता है, इसलिए एक सत्र कॉन्फ़िगर किए गए अनुमोदन सीमा को कम कर सकता है लेकिन विस्तार नहीं कर सकता।

HarnessID OAuth मोड

रिमोट MCP क्लाइंट को HarnessID खोजने और PKCE के साथ OAuth 2.1 प्राधिकरण कोड पूरा करने देने के लिए HARNESS_MCP_MODE=oauth सेट करें। OAuth मोड केवल HTTP ट्रांसपोर्ट के साथ उपलब्ध है। उत्पादन HarnessID, MCP संसाधन, और API रूटिंग डिफ़ॉल्ट अंतर्निहित हैं:

HARNESS_MCP_MODE=oauth

यह डिफ़ॉल्ट रूप से जारीकर्ता https://id.harness.io/idp/realms/HarnessIDP, संसाधन https://mcp.harness.io/mcp, OAuth क्लाइंट mcp-client, और Harness API आधार https://mcp.harness.io/cli पर जाता है। उन्हें केवल QA, स्थानीय विकास, या किसी अन्य Harness वातावरण के लिए ओवरराइड करें।

इस मोड में HARNESS_API_KEY सेट नहीं होना चाहिए। HARNESS_MCP_OAUTH_JWKS_URI डिफ़ॉल्ट रूप से <issuer>/protocol/openid-connect/certs होता है, और HARNESS_ACCOUNT_ID अनावश्यक है क्योंकि खाता टोकन से आता है।

सर्वर RFC 9728 संरक्षित-संसाधन मेटाडेटा प्रकाशित करता है और यह चुनौती लौटाता है जब क्लाइंट ने प्रमाणीकरण नहीं किया है:

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

यह कॉन्फ़िगर किए गए JWKS एंडपॉइंट का उपयोग करके HarnessID एक्सेस टोकन के RS256 हस्ताक्षर, iss, समाप्ति, और sub को मान्य करता है, और जांचता है कि टोकन azp दावे के माध्यम से HARNESS_MCP_OAUTH_CLIENT_ID को जारी किया गया था। HARNESS_MCP_OAUTH_RESOURCE खोज और चुनौतियों के लिए उपयोग किया जाने वाला RFC 9728 संरक्षित-संसाधन पहचानकर्ता है। वर्तमान HarnessID एक्सेस टोकन MCP URL के बजाय aud: account का उपयोग करते हैं, इसलिए संसाधन की तुलना aud से नहीं की जाती है।

खाता ID टोकन के HARNESS_MCP_OAUTH_ACCOUNT_CLAIM दावे (डिफ़ॉल्ट रूप से account_id) से आता है, जिसे HarnessID organization स्कोप आबाद करता है। प्रत्येक सत्र कॉलर के एक्सेस टोकन को संग्रहीत करता है और इसे Authorization: Bearer के रूप में Harness API को अग्रेषित करता है, इसलिए Harness RBAC और ऑडिट रिकॉर्ड साझा PAT के बजाय लॉग-इन उपयोगकर्ता को दर्शाते हैं। सत्र उस sub और खाते से बंधा होता है जिसके साथ इसे बनाया गया था: बाद का अनुरोध एक ताज़ा टोकन ले जा सकता है, लेकिन किसी भिन्न उपयोगकर्ता या खाते के लिए एक को अस्वीकार कर दिया जाता है।

क्लाइंट को आमतौर पर केवल MCP संसाधन URL की आवश्यकता होती है:

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

क्लाइंट संरक्षित-संसाधन मेटाडेटा पढ़ता है, HARNESS_MCP_OAUTH_ISSUER खोजता है, और फिर उस प्राधिकरण सर्वर के RFC 8414 मेटाडेटा का उपयोग करता है। यदि क्लाइंट गतिशील क्लाइंट पंजीकरण का समर्थन नहीं करता है, तो पूर्व-पंजीकृत mcp-client क्लाइंट ID का उपयोग करें।

QA Keycloak चेकलिस्ट और सत्यापन कमांड के लिए स्व-होस्टेड MCP सर्वर के लिए HarnessID OAuth देखें।

बहु-उपयोगकर्ता मोड

साझा HTTP तैनाती के लिए HARNESS_MCP_MODE=multi-user सेट करें जहां प्रत्येक क्लाइंट एक अलग Harness उपयोगकर्ता के रूप में प्रमाणित होता है। इस मोड में:

• HARNESS_API_KEY को सर्वर कॉन्फ़िगरेशन में नहीं सेट किया जाना चाहिए — सर्वर कोई Harness क्रेडेंशियल नहीं रखता है।
• प्रत्येक सत्र को initialize अनुरोध पर x-harness-api-key प्रदान करना होगा। x-harness-account-id केवल तभी आवश्यक है जब API कुंजी खाता खंड एम्बेड नहीं करती है।
• सत्र उस सत्र के लिए डिफ़ॉल्ट दायरा सेट करने के लिए x-harness-org और x-harness-project हेडर भी प्रदान कर सकते हैं।
• Harness API कुंजी उस सत्र के लिए हर Harness API कॉल तक प्रवाहित होती है, इसलिए Harness में ऑडिट ट्रेल वास्तविक उपयोगकर्ता को दर्शाता है।
• HARNESS_MCP_AUTH_TOKEN स्वतंत्र है और अभी भी अतिरिक्त ट्रांसपोर्ट-परत गेट के रूप में उपयोग किया जा सकता है।

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

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

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

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

HARNESS_MCP_ALLOWED_HOSTS DNS-रीबाइंडिंग सुरक्षा के लिए Host-हेडर सत्यापन को नियंत्रित करता है, और CORS ब्राउज़र मूल को सीमित करता है। न तो प्रमाणीकरण है; एक्सेस नियंत्रण के लिए HARNESS_MCP_AUTH_TOKEN या एक प्रमाणित गेटवे/रिवर्स प्रॉक्सी का उपयोग करें।

क्लाइंट कॉन्फ़िगरेशन

नोट: HARNESS_ORG और HARNESS_PROJECT वैकल्पिक हैं। वे org ID और project ID सेट करते हैं जिनका उपयोग तब किया जाता है जब प्रति टूल कॉल निर्दिष्ट नहीं होता है। एजेंट harness_list(resource_type="organization") और harness_list(resource_type="project") का उपयोग करके संगठनों और प्रोजेक्ट्स को गतिशील रूप से खोज सकते हैं। पिछड़े संगतता के लिए पुराने नाम HARNESS_DEFAULT_ORG_ID और HARNESS_DEFAULT_PROJECT_ID अभी भी स्वीकार किए जाते हैं।

होस्टेड Harness MCP

Harness उन खातों के लिए एक होस्टेड MCP एंडपॉइंट भी समर्थन करता है जिनमें प्रबंधित सेवा सक्षम है। यह तब उपयोगी होता है जब आप npx harness-mcp-v2 चलाने या HTTP ट्रांसपोर्ट को स्वयं होस्ट करने के बजाय एक साझा रिमोट MCP एंडपॉइंट चाहते हैं।

महत्वपूर्ण: होस्टेड MCP प्रमाणीकरण Harness Platform OAuth का उपयोग करता है। यह क्लाइंट कॉन्फ़िगरेशन में HARNESS_API_KEY का उपयोग नहीं करता है। होस्टेड MCP उपलब्धता प्रति Harness खाते के अनुसार कॉन्फ़िगर की जाती है, इसलिए उपयोग से पहले सेटिंग को सक्षम/कॉन्फ़िगर करने के लिए आपको Harness Support के साथ काम करना होगा।

होस्टेड एंडपॉइंट https://mcp.harness.io/mcp एक प्रबंधित सेवा है। Claude, Cursor, या Cowork में क्लाइंट-साइड MCP कॉन्फ़िगरेशन यह निर्धारित नहीं कर सकता कि यह किस Harness वातावरण में रूट होता है। Harness0 या किसी अन्य निजी Harness SaaS वातावरण के लिए, उस वातावरण के लिए होस्टेड MCP सक्षम/कॉन्फ़िगर करने के लिए Harness Support से पूछें, या स्थानीय/सेल्फ-होस्टेड सर्वर चलाएं और HARNESS_BASE_URL को लक्षित Harness होस्ट पर सेट करें।

होस्टेड MCP उदाहरण:

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

होस्टेड और स्थानीय दोनों प्रविष्टियों वाला उदाहरण:

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

npx ENOENT या node: No such file or directory का समस्या निवारण

यह क्लाइंट प्रक्रिया-लॉन्च विफलता है, Harness प्रमाणीकरण विफलता नहीं। MCP सर्वर अभी शुरू नहीं हुआ है, इसलिए HARNESS_API_KEY बदलने से spawn npx ENOENT प्रभावित नहीं होगा।

GUI ऐप्स (Cursor, Claude Desktop, Devin Desktop, VS Code) हमेशा आपके शेल का PATH इनहेरिट नहीं करते, इसलिए कॉन्फ़िगरेशन रीलोड के बाद वे npx या node खोजने में विफल हो सकते हैं। इसे निरपेक्ष पथों का उपयोग करके और env ब्लॉक में PATH स्पष्ट रूप से सेट करके ठीक करें:

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

टर्मिनल में which npx और which node के साथ अपने पथ खोजें, फिर सुनिश्चित करें कि node वाला निर्देशिका उपरोक्त PATH मान में शामिल है। सामान्य स्थान:

• Homebrew (macOS): /opt/homebrew/bin/npx
• nvm: ~/.nvm/versions/node/v20.x.x/bin/npx (सटीक पथ खोजने के लिए nvm which current चलाएं)
• 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

फिर अपने वातावरण या .env फ़ाइल में HARNESS_API_KEY सेट करें।

Cursor (.cursor/mcp.json)

npx (शून्य इंस्टॉल, स्थानीय Cursor कॉन्फ़िगरेशन के लिए अनुशंसित)

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

टर्मिनल में which npx चलाएं और command के लिए उस पूर्ण पथ का उपयोग करें; PATH के सामने which node से निर्देशिका शामिल करें।

node (स्थानीय इंस्टॉल)

npm install -g harness-mcp-v2

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

npm install -g harness-mcp-v2 के बाद which harness-mcp-v2 चलाएं और command के लिए उस पूर्ण पथ का उपयोग करें; PATH के सामने which node से निर्देशिका शामिल करें।

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

npx (शून्य इंस्टॉल)

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

node (स्थानीय इंस्टॉल)

npm install -g harness-mcp-v2

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

स्रोत से स्थानीय बिल्ड का उपयोग कर रहे हैं?

कमांड को अपने निर्मित index.js के पथ से बदलें:

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

MCP गेटवे

Harness MCP सर्वर MCP गेटवे के साथ पूरी तरह संगत है — रिवर्स प्रॉक्सी जो कई MCP सर्वरों में केंद्रीकृत प्रमाणीकरण, शासन, टूल रूटिंग, और अवलोकन प्रदान करते हैं। चूंकि सर्वर stdio और HTTP दोनों ट्रांसपोर्ट के साथ मानक MCP प्रोटोकॉल लागू करता है, यह बिना कोड परिवर्तन के किसी भी MCP-अनुरूप गेटवे के पीछे काम करता है।

गेटवे का उपयोग क्यों करें?

• केंद्रीकृत क्रेडेंशियल प्रबंधन — एजेंट कॉन्फ़िगरेशन में कोई API कुंजी नहीं
• टीमों में सभी टूल कॉल के लिए शासन और ऑडिट लॉगिंग
• N MCP सर्वरों के लिए N कनेक्शन के बजाय एजेंटों के लिए एकल एंडपॉइंट
• एक्सेस नियंत्रण — प्रतिबंधित करें कि कौन सी टीमें कौन से टूल का उपयोग कर सकती हैं

Docker MCP गेटवे

अपने Docker MCP गेटवे कॉन्फ़िगरेशन में सर्वर पंजीकृत करें:

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

Portkey

एंटरप्राइज़ शासन, लागत ट्रैकिंग, और मल्टी-LLM रूटिंग के लिए अपने Portkey MCP Gateway में Harness MCP सर्वर जोड़ें:

{
  "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 गेटवे

सर्वर HTTP ट्रांसपोर्ट के माध्यम से Envoy AI Gateway के MCP समर्थन के साथ काम करता है:

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

फिर Envoy को अपस्ट्रीम MCP बैकएंड के रूप में http://localhost:8080/mcp पर रूट करने के लिए कॉन्फ़िगर करें।

Kong

अपने मौजूदा Kong गेटवे इंफ्रास्ट्रक्चर के माध्यम से Harness MCP सर्वर को उजागर करने के लिए Kong के AI MCP प्रॉक्सी प्लगइन का उपयोग करें।

अन्य गेटवे

कोई भी गेटवे जो MCP विनिर्देशन का समर्थन करता है (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers, आदि) इस सर्वर को प्रॉक्सी कर सकता है। stdio-आधारित गेटवे के लिए, डिफ़ॉल्ट ट्रांसपोर्ट का उपयोग करें। HTTP-आधारित गेटवे के लिए, सर्वर को http ट्रांसपोर्ट के साथ शुरू करें और गेटवे को /mcp एंडपॉइंट पर इंगित करें।

Docker

सर्वर को Docker कंटेनर के रूप में बनाएं और चलाएं:

# Build the image
pnpm docker:build

# Run with your .env file
pnpm docker:run

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

कंटेनर डिफ़ॉल्ट रूप से पोर्ट 3000 पर HTTP मोड में अंतर्निहित स्वास्थ्य जांच के साथ चलता है।

Kubernetes

प्रदान किए गए मेनिफेस्ट का उपयोग करके Kubernetes क्लस्टर में तैनात करें:

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

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

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

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

तैनाती रेडिनेस/लाइवनेस प्रोब, संसाधन सीमाएं, और गैर-रूट सुरक्षा संदर्भ के साथ 2 रेप्लिका चलाती है। सेवा आंतरिक रूप से पोर्ट 80 को उजागर करती है (कंटेनर पोर्ट 3000 को लक्षित करते हुए)।

कॉन्फ़िगरेशन

सर्वर स्वचालित रूप से प्रोजेक्ट रूट में .env फ़ाइल से पर्यावरण चर लोड करता है यदि एक मौजूद है। .env.example को .env पर कॉपी करें और अपने मान भरें। पर्यावरण चर आपके शेल या MCP क्लाइंट कॉन्फ़िगरेशन के माध्यम से भी सेट किए जा सकते हैं।

चर	आवश्यक	डिफ़ॉल्ट	विवरण
HARNESS_MCP_MODE	नहीं	single-user	परिनियोजन मोड: single-user (साझा API कुंजी), multi-user (प्रति-सत्र API कुंजियों के साथ HTTP), या oauth (HarnessID एक्सेस-टोकन सत्यापन के साथ HTTP)
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 (OAuth मोड में https://mcp.harness.io/cli)	Harness API/UI आधार URL। OAuth मोड डिफ़ॉल्ट रूप से होस्ट किए गए MCP /cli प्रॉक्सी के माध्यम से रूट करता है; अन्य मोड Harness SaaS API का सीधे उपयोग करते हैं
HARNESS_MCP_OAUTH_ISSUER	नहीं	https://id.harness.io/idp/realms/HarnessIDP	HarnessID जारीकर्ता एक्सेस टोकन iss दावे के विरुद्ध बिल्कुल मिलान किया गया
HARNESS_MCP_OAUTH_RESOURCE	नहीं	https://mcp.harness.io/mcp	सार्वजनिक विहित MCP URL RFC 9728 संसाधन पहचानकर्ता के रूप में प्रकाशित
HARNESS_MCP_OAUTH_JWKS_URI	नहीं	<issuer>/protocol/openid-connect/certs	HarnessID JWKS एंडपॉइंट RS256 एक्सेस-टोकन हस्ताक्षर सत्यापित करने के लिए उपयोग किया जाता है
HARNESS_MCP_OAUTH_CLIENT_ID	नहीं	mcp-client	HarnessID क्लाइंट जिसे एक्सेस टोकन जारी किया जाना चाहिए, टोकन के azp दावे के विरुद्ध जांचा गया
HARNESS_MCP_OAUTH_ACCOUNT_CLAIM	नहीं	account_id	एक्सेस-टोकन दावा जो Harness खाता ID रखता है, HarnessID organization स्कोप द्वारा आबाद
HARNESS_MCP_OAUTH_SCOPES	नहीं	openid profile email organization	RFC 9728 संरक्षित-संसाधन मेटाडेटा में विज्ञापित स्पेस-पृथक स्कोप
HARNESS_FME_API_KEY	नहीं	--	वैकल्पिक एकल-उपयोगकर्ता/स्व-होस्टेड FME/Split व्यवस्थापक क्रेडेंशियल केवल विरासत (workspace_id) मोड में fme_ संसाधनों के लिए उपयोग किया जाता है। विरासत FME OAuth मोड में अनुपलब्ध है इसलिए HarnessID टोकन कभी भी api.split.io को नहीं भेजे जाते हैं; इसके बजाय Harness-मूल org_id+project_id स्कोप का उपयोग करें। multi-user या oauth मोड में सेट नहीं होना चाहिए
HARNESS_FME_BASE_URL	नहीं	https://api.split.io	Split/FME व्यवस्थापक API आधार URL केवल विरासत (workspace_id) मोड में fme_ संसाधनों द्वारा उपयोग किया जाता है। HTTP URL को स्थानीय विकास के लिए HARNESS_ALLOW_HTTP=true की आवश्यकता होती है। Harness-मूल (org_id+project_id) मोड इसे अनदेखा करता है और इसके बजाय मानक HARNESS_API_KEY/HARNESS_BASE_URL का उपयोग करता है
HARNESS_ORG	नहीं	--	संगठन ID। उपयोग किया जाता है जब org_id प्रति टूल कॉल निर्दिष्ट नहीं होता है। यदि छोड़ा गया है, तो org_id स्पष्ट रूप से प्रदान किया जाना चाहिए। एजेंट harness_list(resource_type="organization") के माध्यम से संगठनों को गतिशील रूप से भी खोज सकते हैं
HARNESS_PROJECT	नहीं	--	परियोजना ID। उपयोग किया जाता है जब project_id प्रति टूल कॉल निर्दिष्ट नहीं होता है। एजेंट harness_list(resource_type="project") के माध्यम से परियोजनाओं को गतिशील रूप से भी खोज सकते हैं
HARNESS_API_TIMEOUT_MS	नहीं	30000	HTTP अनुरोध टाइमआउट मिलीसेकंड में
HARNESS_MAX_RETRIES	नहीं	3	क्षणिक विफलताओं के लिए पुनः प्रयास गणना (429, 5xx)
HARNESS_MAX_BODY_SIZE_MB	नहीं	10	http परिवहन के लिए अधिकतम HTTP अनुरोध निकाय आकार MB में
HARNESS_RATE_LIMIT_RPS	नहीं	10	Harness 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	गैर-HTTPS HARNESS_BASE_URL की अनुमति दें। डिफ़ॉल्ट रूप से, सर्वर सुरक्षा के लिए HTTPS लागू करता है। गैर-TLS Harness इंस्टेंस के विरुद्ध केवल स्थानीय विकास के लिए true पर सेट करें
HARNESS_PIPELINE_VERSION	नहीं	0	(अल्फा) पाइपलाइन YAML संस्करण। 0 pipeline संसाधन प्रकार लोड करता है और pipeline_v1 को बाहर करता है; 1 pipeline_v1 लोड करता है और pipeline को बाहर करता है। HTTP सत्र इसे आरंभीकरण समय पर x-harness-pipeline-version: 0 या 1 के साथ ओवरराइड कर सकते हैं
HARNESS_MCP_ALLOWED_HOSTS	नहीं	--	HTTP परिवहन होस्ट-हेडर सत्यापन द्वारा अनुमत अल्पविराम-पृथक होस्टनाम। लोकलहोस्ट बाइंड के लिए डिफ़ॉल्ट रूप से mcp.harness.io की अनुमति है; प्रॉक्सी/कस्टम डोमेन यहां जोड़ें
HARNESS_MCP_AUTH_TOKEN	नहीं	--	सेट होने पर /mcp HTTP मार्गों पर आवश्यक स्थिर Bearer टोकन। गैर-लूपबैक एकल-उपयोगकर्ता और बहु-उपयोगकर्ता बाइंड के लिए डिफ़ॉल्ट रूप से आवश्यक। oauth मोड में अनसेट होना चाहिए
HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP	नहीं	false	गैर-लूपबैक बाइंड पर अनप्रमाणित HTTP परिवहन को स्पष्ट रूप से अनुमति दें। केवल किसी अन्य प्रमाणित नियंत्रण के पीछे उपयोग करें
HARNESS_MCP_TRUST_PROXY	नहीं	0	क्लाइंट IP समाधान के लिए भरोसा करने के लिए रिवर्स प्रॉक्सी / लोड बैलेंसर हॉप्स की संख्या (एक्सप्रेस 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 एंडपॉइंट जो बैच किए गए ऑडिट ईवेंट प्राप्त करता है। HTTP URL को स्थानीय विकास के लिए 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 (सिमेंटिक खोज अक्षम करें, केवल कीवर्ड स्कैटर-गैदर पर वापस जाएं)। एयर-गैप्ड वातावरण में या जब स्टार्टअप मॉडल लोडिंग अवांछनीय हो, तब 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	local खोज प्रदाता द्वारा उपयोग किए जाने वाले @huggingface/transformers मॉडल कैश के लिए निर्देशिका। Docker इमेज मॉडल को /app/.cache/hf में पहले से बेक करती है ताकि रनटाइम डाउनलोड से बचा जा सके। प्रोडक्शन डिप्लॉयमेंट में एक स्थायी वॉल्यूम पथ पर सेट करें
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	नहीं	3	विफल चरणों के लिए लॉग प्राप्त करते समय harness_diagnose द्वारा जारी किए गए अधिकतम समवर्ती लॉग-ब्लॉब डाउनलोड। केवल तभी बढ़ाएं जब निदान विलंबता लॉग-फ़ेच वॉल-क्लॉक द्वारा प्रभावी हो और पॉड में मेमोरी हेडरूम हो

सिमेंटिक खोज

harness_search स्कैटर-गैदर API कॉल्स को Harness तक फैलाने से पहले संकीर्ण करने के लिए सिमेंटिक रूटिंग का उपयोग करता है। तीन खोज प्रदाता उपलब्ध हैं:

प्रदाता	कब उपयोग करें
local (डिफ़ॉल्ट)	सिंगल-यूज़र stdio मोड। all-MiniLM-L6-v2 को @huggingface/transformers के माध्यम से इन-प्रोसेस चलाता है। पहले उपयोग पर ~23 MB मॉडल डाउनलोड करता है; बाद के स्टार्ट कैश का उपयोग करते हैं।
remote	मल्टी-यूज़र HTTP मोड (Harness-होस्टेड)। एम्बेडिंग और पुनर्प्राप्ति को बाहरी खोज सेवा को सौंपता है। टेनेंट अलगाव tenant_id के माध्यम से लागू किया जाता है — स्थिर ज्ञान/दस्तावेज़ global का उपयोग करते हैं, प्रति-खाता इकाई डेटा खाता ID का उपयोग करता है।
none	सिमेंटिक खोज को पूरी तरह से अक्षम करें; सभी संसाधन प्रकारों में कीवर्ड स्कैटर-गैदर पर वापस जाता है।

रिमोट प्रदाता कॉन्फ़िगरेशन:

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

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

रिमोट प्रदाता का स्थानीय रूप से परीक्षण शामिल स्टब सेवा के साथ (कोई बाहरी निर्भरता नहीं):

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

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

# 3. Build the MCP server
pnpm build

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

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

स्टब (stub-search-service.py) उत्पादन खोज सेवा के समान /v1/health, /v1/ingest, और /v1/search अनुबंध लागू करता है। यह एक सरल बैग-ऑफ-कैरेक्टर एम्बेडिंग का उपयोग करता है, इसलिए कोई मॉडल डाउनलोड आवश्यक नहीं है — परिणाम सिमेंटिक रूप से प्रशंसनीय हैं लेकिन उत्पादन-गुणवत्ता के नहीं हैं।

HTTPS प्रवर्तन

HARNESS_BASE_URL को डिफ़ॉल्ट रूप से HTTPS का उपयोग करना चाहिए। यदि आप एक गैर-HTTPS URL सेट करते हैं (जैसे http://localhost:8080), तो सर्वर इसके साथ शुरू करने से इनकार कर देगा:

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

ऑडिट लॉगिंग

सभी रजिस्ट्री-डिस्पैच किए गए Harness API ऑपरेशन (list, get, create, update, delete, और execute) संरचित ऑडिट इवेंट उत्सर्जित करते हैं जब ऑडिट सिंक कॉन्फ़िगर किए जाते हैं। उत्परिवर्तन इवेंट में पुष्टिकरण पथ शामिल होता है जो elicitation या स्वतः-अनुमोदन द्वारा उपयोग किया जाता है जब पुष्टिकरण संदर्भ मौजूद होता है; पढ़ने के इवेंट वर्तमान में पुष्टिकरण मेटाडेटा को छोड़ देते हैं। स्थानीय मेटाडेटा और स्कीमा खोज उपकरण जो रजिस्ट्री को बायपास करते हैं, जैसे harness_describe और harness_schema, इस ऑडिट स्ट्रीम का हिस्सा नहीं हैं। एक stderr सिंक डिफ़ॉल्ट रूप से पंजीकृत है लेकिन सामान्य लॉगर से गुजरता है और LOG_LEVEL का पालन करता है; स्थायी ऑडिट संग्रह के लिए फ़ाइल या वेबहुक सिंक कॉन्फ़िगर करें:

• HARNESS_AUDIT_FILE स्थानीय संग्रह के लिए न्यूलाइन-सीमांकित JSON इवेंट जोड़ता है।
• HARNESS_AUDIT_WEBHOOK_URL { "events": [...] } बैचों को एक HTTPS वेबहुक पर पोस्ट करता है, वैकल्पिक रूप से HARNESS_AUDIT_WEBHOOK_TOKEN के साथ। असफल बैचों को सीमित क्षमता के साथ फिर से कतारबद्ध किया जाता है और अंततः टूल निष्पादन को अवरुद्ध करने के बजाय चेतावनी के साथ छोड़ दिया जाता है।
• OTEL_EXPORTER_OTLP_ENDPOINT वैकल्पिक OpenTelemetry सहकर्मी निर्भरताएँ स्थापित होने पर ऑडिट स्पैन सक्षम करता है। सिंक एक मौजूदा ट्रेसर प्रदाता का पुन: उपयोग करता है जब एक पंजीकृत होता है, अन्यथा यह एक स्टैंडअलोन OTLP एक्सपोर्टर बूटस्ट्रैप करता है।

प्रत्येक इवेंट में टूल नाम, संसाधन प्रकार, ऑपरेशन, पहचानकर्ता, टाइमस्टैम्प, जोखिम, परिणाम, HTTP विधि/पथ, अवधि, और लागू होने पर पुष्टिकरण विधि शामिल होती है। ऑडिट सिंक सर्वोत्तम-प्रयास टेलीमेट्री हैं; वितरण समस्याएँ लॉग की जाती हैं और अंतर्निहित Harness API ऑपरेशन को कभी दोहराती या बदलती नहीं हैं। OTel सेटअप विवरण और स्पैन विशेषताओं के लिए, specs/005-otel-audit-sink.md देखें।

टूल्स संदर्भ

सर्वर 11 MCP टूल्स उजागर करता है। अधिकांश API टूल्स org_id और project_id को वैकल्पिक ओवरराइड के रूप में स्वीकार करते हैं — यदि छोड़ दिया जाता है, तो वे HARNESS_ORG और HARNESS_PROJECT पर वापस आ जाते हैं। harness_describe केवल स्थानीय मेटाडेटा है और org/project स्कोप का उपयोग नहीं करता है।

URL समर्थन: अधिकांश API-सामना करने वाले टूल्स एक url पैरामीटर स्वीकार करते हैं — एक Harness UI URL पेस्ट करें और सर्वर स्वचालित रूप से org, project, संसाधन प्रकार, संसाधन ID, पाइपलाइन ID, और निष्पादन ID निकालता है। harness_describe url स्वीकार नहीं करता है।

स्कोप समर्थन: खाता/org/project वेरिएंट वाले संसाधन प्रकार harness_describe में supportedScopes उजागर करते हैं। जब आपको एक विशिष्ट स्तर की आवश्यकता हो तो resource_scope पास करें:

• resource_scope: "account" केवल accountIdentifier भेजता है।
• resource_scope: "org" accountIdentifier और orgIdentifier भेजता है।
• resource_scope: "project" खाता, org, और project पहचानकर्ता भेजता है।

वर्तमान मल्टी-स्कोप संसाधनों में connector, service, environment, infrastructure, secret, file_store, template, policy, और policy_set शामिल हैं। यदि resource_scope छोड़ दिया जाता है, तो रजिस्ट्री संसाधन के डिफ़ॉल्ट स्कोप और कॉन्फ़िगर किए गए डिफ़ॉल्ट का उपयोग करती है, सिवाय वैकल्पिक स्कोप के रूप में चिह्नित संसाधनों के जो org/project को छोड़ सकते हैं जब तक स्पष्ट रूप से पास न किया जाए। Harness URLs पथ में खाता-स्तर या project-स्तर संदर्भ होने पर स्कोप को स्वचालित रूप से सेट कर सकते हैं।

संरचित आउटपुट: प्रत्येक टूल एक MCP outputSchema घोषित करता है। harness_list सूची-जैसे Harness प्रतिक्रियाओं को ऑब्जेक्ट-आकार की संरचित सामग्री में सामान्यीकृत करता है ताकि सख्त क्लाइंट इसे मान्य कर सकें: शीर्ष-स्तरीय सरणियाँ { "items": [...], "total": <count>, "page": <page> } बन जाती हैं, और सामान्य रैपर कुंजियाँ जैसे content, data, body, objects, या features आवश्यकता होने पर items तक उठाई जाती हैं। टेक्स्ट प्रतिक्रिया में अभी भी सभी क्लाइंट्स को लौटाया गया कॉम्पैक्ट JSON पेलोड होता है।

टूल	विवरण
harness_describe	उपलब्ध संसाधन प्रकार, संचालन और फ़ील्ड खोजें। कोई API कॉल नहीं — स्थानीय रजिस्ट्री मेटाडेटा लौटाता है।
harness_schema	संसाधन बनाने/अपडेट करने के लिए सटीक YAML/JSON स्कीमा परिभाषाएँ और उदाहरण प्राप्त करें। पाइपलाइन/टेम्पलेट स्कीमा बंडल किए गए हैं; कनेक्टर, पर्यावरण, सेवा, गुप्त और इन्फ्रास्ट्रक्चर स्कीमा स्कोप-जागरूक एंटिटी स्कीमा हैं जो बंडल स्नैपशॉट या 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 संसाधन प्रकारों में खोजें। सिमेंटिक रूटिंग (स्थानीय all-MiniLM-L6-v2 ONNX एम्बेडिंग, 384-आयामी) का उपयोग करके स्टार्टअप पर अनुक्रमित knowledge कॉर्पस से प्रासंगिक संसाधन प्रकारों की भविष्यवाणी करता है — आमतौर पर स्कैटर-गैदर से पहले ~163 प्रकारों से 1–8 तक संकुचित करता है। जब सिमेंटिक विश्वास कम होता है तो पूर्ण कीवर्ड स्कैटर-गैदर पर वापस आ जाता है। रूटिंग सक्रिय होने पर प्रतिक्रिया में semantic_routed और types_skipped शामिल होते हैं। नए संसाधन प्रकारों को खोजने योग्य बनाने के तरीके के लिए docs/search-guidelines.md देखें।
harness_diagnose	pipeline, connector, delegate, और gitops_application संसाधनों का निदान करें (उपनाम: execution -> pipeline, gitops_app -> gitops_application)। पाइपलाइनों के लिए, स्टेज/स्टेप समय और विफलता विवरण लौटाता है; कनेक्टर/डेलीगेट/GitOps ऐप्स के लिए, लक्षित स्वास्थ्य और समस्या निवारण संकेत लौटाता है।
harness_status	रीयल-टाइम प्रोजेक्ट स्वास्थ्य डैशबोर्ड प्राप्त करें — हाल के निष्पादन, विफलता दर और गहरे लिंक।

स्कीमा लुकअप वर्कफ़्लो

YAML-समर्थित संसाधन बनाने या अपडेट करने से पहले harness_schema का उपयोग करें ताकि एजेंट गद्य से अनुमान लगाने के बजाय सटीक फ़ील्ड नाम और बाधाओं की प्रतिलिपि बना सकें।

• बंडल स्कीमा में pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1, और agent-pipeline शामिल हैं।
• एंटिटी स्कीमा में connector, environment, service, secret, और infrastructure शामिल हैं। वे स्कोप-जागरूक हैं (account, org, या project) और चयनित स्कोप की आवश्यकता होने पर org_id/project_id की आवश्यकता होती है।
• रिलीज़ प्रबंधन परिभाषाएँ (release_process, release_activity) RMG /api/yamlSchema से लाइव JSON स्कीमा प्राप्त करती हैं (बंडल नहीं)। ऑर्ग या प्रोजेक्ट में स्कोप करते समय scope, org_id, और project_id पास करें।
• वेंडर किए गए एंटिटी स्नैपशॉट पहले उपयोग किए जाते हैं जब वे रनटाइम खाते से मेल खाते हैं; अन्यथा टूल Harness NG /yaml-schema API पर वापस आ जाता है और परिणाम कैश करता है।
• फ़ील्ड/अनुभाग सारांश के लिए path छोड़ें, फिर नेस्टेड परिभाषा का निरीक्षण करने के लिए डॉट-सेपरेटेड path पास करें।

उदाहरण:

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

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

जब Harness एंटिटी YAML स्कीमा बदलते हैं तो अनुरक्षक pnpm sync-entity-schemas के साथ वेंडर किए गए एंटिटी स्नैपशॉट को रीफ्रेश कर सकते हैं।

टूल उदाहरण

पता लगाएं कि कौन से संसाधन उपलब्ध हैं:

{ "resource_type": "pipeline" }

खाते में संगठनों की सूची बनाएं:

{ "resource_type": "organization" }

किसी संगठन में प्रोजेक्ट की सूची बनाएं:

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

किसी प्रोजेक्ट में पाइपलाइनों की सूची बनाएं:

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

कोई विशिष्ट सेवा प्राप्त करें:

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

पाइपलाइन चलाएं:

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

फ़ीचर फ़्लैग टॉगल करें:

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

सभी संसाधन प्रकारों में खोजें:

{ "query": "payment-service" }

आईडी द्वारा निष्पादन का निदान करें (सारांश मोड — डिफ़ॉल्ट):

{ "execution_id": "abc123XYZ" }

Harness URL से निदान करें:

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

कनेक्टर कनेक्टिविटी का निदान करें:

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

डेलीगेट स्वास्थ्य का निदान करें:

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

GitOps एप्लिकेशन का निदान करें (विकल्पों के साथ):

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

पाइपलाइन के लिए नवीनतम निष्पादन रिपोर्ट प्राप्त करें:

{ "pipeline_id": "my-pipeline" }

YAML और विफल स्टेप लॉग के साथ पूर्ण डायग्नोस्टिक मोड:

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

लॉग सक्षम के साथ सारांश मोड (दोनों का सर्वोत्तम):

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

प्रोजेक्ट स्वास्थ्य स्थिति प्राप्त करें:

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

माइग्रेशन प्रकार द्वारा फ़िल्टर किए गए डेटाबेस स्कीमा की सूची बनाएं:

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

स्कीमा के लिए डेटाबेस इंस्टेंस की सूची बनाएं:

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

स्कीमा और इंस्टेंस के लिए हल की गई LLM लेखन पाइपलाइन प्राप्त करें:

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

स्कीमा इंस्टेंस के लिए स्नैपशॉट ऑब्जेक्ट नामों की सूची बनाएं (जैसे तालिकाएँ):

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

विशिष्ट नामित ऑब्जेक्ट के लिए पूर्ण स्नैपशॉट मेटाडेटा प्राप्त करें:

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

पाइपलाइन रन वर्कफ़्लो (अनुशंसित)

v0 पाइपलाइनों के लिए, निष्पादन-समय इनपुट त्रुटियों को कम करने के लिए इस अनुक्रम का उपयोग करें:

1. आवश्यक रनटाइम इनपुट खोजें

• harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
• लौटाया गया टेम्पलेट <+input> प्लेसहोल्डर दिखाता है जिन्हें मानों की आवश्यकता होती है।

2. इनपुट रणनीति चुनें

• सरल चर: फ्लैट की-वैल्यू inputs पास करें (उदाहरण के लिए {"branch":"main","env":"prod"})।

• जटिल/संरचनात्मक इनपुट: input_set_ids का उपयोग करें (CI कोडबेस/बिल्ड ब्लॉक और नेस्टेड टेम्पलेट इनपुट इस तरह सबसे अच्छे से संभाले जाते हैं)।

• CI कोडबेस शॉर्टहैंड कुंजियाँ (केवल पाइपलाइन रन):

  शॉर्टहैंड कुंजी	विस्तारित संरचना
  branch	build.type=branch, build.spec.branch=<value>
  tag	build.type=tag, build.spec.tag=<value>
  pr_number	build.type=PR, build.spec.number=<value>
  commit_sha	build.type=commitSha, build.spec.commitSha=<value>

• बाधा: शॉर्टहैंड विस्तार तब छोड़ दिया जाता है जब inputs.build पहले से मौजूद हो (स्पष्ट build जीतता है)।

3. रन निष्पादित करें

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

• Git-समर्थित पाइपलाइनों के लिए जिनका YAML गैर-डिफ़ॉल्ट शाखा से लोड किया जाना चाहिए, params.pipeline_branch पास करें (Harness को branch के रूप में भेजा जाता है)। यह स्पष्ट परिभाषा चयनकर्ता params.branch उपनाम पर प्राथमिकता लेता है। inputs.branch स्वतंत्र रूप से CI कोडबेस शाखा का चयन करता है:

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

4. वैकल्पिक: दोनों को मिलाएं

• आधार आकार के लिए input_set_ids और सरल ओवरराइड के लिए inputs का उपयोग करें।

v1 पाइपलाइनों के लिए:

1. harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>") प्राप्त करें। Git-समर्थित पाइपलाइनों के लिए, branch_name, connector_ref, और repo_name को params के माध्यम से पास करें।
2. प्रत्येक लौटाए गए inputs[].details.name को harness_execute.inputs में शीर्ष-स्तरीय कुंजी के रूप में उपयोग करें।
3. harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}) चलाएं। सर्वर इन मानों को inputs: YAML रूट के अंतर्गत लपेटता है और API का inputs_yaml बॉडी भेजता है।

यदि आवश्यक फ़ील्ड हल नहीं हो पाते हैं, तो टूल अपेक्षित कुंजियों और सुझाए गए इनपुट सेट के साथ प्री-फ्लाइट त्रुटि लौटाता है। आप harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands) के साथ उपलब्ध शॉर्टहैंड मैपिंग का निरीक्षण कर सकते हैं।

डायनामिक पाइपलाइन निष्पादन

pipeline_dynamic_execution.run का उपयोग तब करें जब कोई एजेंट या बाहरी सिस्टम रनटाइम पर पूर्ण v0 पाइपलाइन YAML उत्पन्न करता है और उसे मौजूदा Harness पाइपलाइन शेल के विरुद्ध चलाने की आवश्यकता होती है। यह सामान्य pipeline.run का प्रतिस्थापन नहीं है: सहेजी गई v0 पाइपलाइन पहले से मौजूद होनी चाहिए, खाता-स्तर और पाइपलाइन-स्तर Allow Dynamic Execution सक्षम होना चाहिए, और कॉल करने वाले के पास पाइपलाइन पर Edit और Execute अनुमतियाँ होनी चाहिए।

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

बाधाएँ:

• body एक yaml फ़ील्ड वाली वस्तु होनी चाहिए। कच्चे स्ट्रिंग बॉडी को सार्वजनिक harness_execute स्कीमा द्वारा अस्वीकार कर दिया जाता है।
• body.yaml एक YAML स्ट्रिंग या JSON पाइपलाइन ऑब्जेक्ट हो सकता है; अनुरोध से पहले JSON को YAML में क्रमबद्ध किया जाता है।
• रनटाइम <+input> प्लेसहोल्डर इस API द्वारा हल नहीं किए जाते हैं। पूरी तरह से हल किया गया YAML सबमिट करें।
• इनपुट सेट, चयनात्मक चरण निष्पादन, पुनः प्रयास और ट्रिगर डायनामिक निष्पादन एंडपॉइंट द्वारा समर्थित नहीं हैं।
• क्रिया high_write है और सामान्य पुष्टिकरण/स्वतः-अनुमोदन पथ का उपयोग करती है। प्रतिक्रिया API आवरण को { "execution_id": "...", "status": "..." } पर प्रोजेक्ट करती है और जब स्कोप डेटा उपलब्ध होता है तो एक openInHarness निष्पादन लिंक शामिल करती है।

यदि Harness रन को सक्षम नहीं के रूप में अस्वीकार करता है, तो खाता-स्तर Allow Dynamic Execution सेटिंग और पाइपलाइन-स्तर टॉगल दोनों को Pipeline -> Advanced Options -> Dynamic Execution Settings के अंतर्गत जाँचें।

निष्पादन इनपुट फोरेंसिक

रन के बाद किसी विशिष्ट निष्पादन को उत्पन्न करने वाले विलय किए गए इनपुट YAML का निरीक्षण करने के लिए execution_inputs का उपयोग करें। यह तब उपयोगी होता है जब कोई विफलता इनपुट-सेट विलय, Git-समर्थित इनपुट सेट शाखाओं, या ट्रिगर/रनटाइम मानों पर निर्भर करती है जिन्हें अकेले निष्पादन पृष्ठ से पुनर्निर्माण करना कठिन होता है।

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

get प्रतिक्रिया निम्न पर प्रोजेक्ट की जाती है:

• executionId - resource_id से प्लान निष्पादन ID।
• inputSetYaml - रन के लिए उपयोग किया गया विलय किया गया रनटाइम इनपुट YAML, या null।
• inputSetTemplateYaml - निष्पादन समय पर इनपुट टेम्पलेट, या null।
• resolvedYaml - अभिव्यक्ति-हल किया गया YAML जब resolve_expressions=true, अन्यथा आमतौर पर null।
• inputSetDetails - योगदान देने वाले सहेजे गए इनपुट सेट { identifier, name } जोड़े के रूप में।
• inputSetBranchName - Git-समर्थित इनपुट सेट के लिए स्रोत शाखा, या null।

execution_inputs केवल-पढ़ने योग्य और पढ़ने-जोखिम है। यदि 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.5x से पीछे हटता है, और 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 एजेंट से पाइपलाइन बनाने के लिए कहें:

{
  "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 पाइपलाइनों को तीन तरीकों से संग्रहीत किया जा सकता है:

मोड	विवरण	कब उपयोग करें
इनलाइन	पाइपलाइन YAML Harness में संग्रहीत	डिफ़ॉल्ट। सबसे सरल सेटअप, Git की आवश्यकता नहीं।
रिमोट (बाहरी Git)	पाइपलाइन YAML GitHub, GitLab, Bitbucket आदि में संग्रहीत।	बाहरी प्रदाता के साथ Git-समर्थित पाइपलाइन-एज़-कोड का उपयोग करने वाली टीमें।
रिमोट (Harness Code)	पाइपलाइन YAML Harness Code रिपॉजिटरी में संग्रहीत	Harness के अंतर्निहित Git होस्टिंग का उपयोग करने वाली टीमें।

एक इनलाइन पाइपलाइन बनाएं (डिफ़ॉल्ट):

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

एक रिमोट पाइपलाइन बनाएं (बाहरी Git — जैसे GitHub):

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

एक रिमोट पाइपलाइन बनाएं (Harness Code — कोई कनेक्टर आवश्यक नहीं):

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

एक रिमोट पाइपलाइन अपडेट करें:

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

बाहरी Git रिपो से पाइपलाइन आयात करें:

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

Harness Code रिपो से पाइपलाइन आयात करें:

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

एक कनेक्टर बनाएं:

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

एक ट्रिगर हटाएं:

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

पाइपलाइन के लिए इनपुट सेट सूचीबद्ध करें:

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

एक विशिष्ट इनपुट सेट प्राप्त करें:

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

एक इनपुट सेट बनाएं:

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

एक इनपुट सेट अपडेट करें:

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

एक इनपुट सेट हटाएं:

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

संसाधन प्रकार

41 टूलसेट में 255 संसाधन प्रकार व्यवस्थित हैं। प्रत्येक संसाधन प्रकार CRUD संचालन और वैकल्पिक निष्पादन क्रियाओं के एक सबसेट का समर्थन करता है।

प्लेटफ़ॉर्म

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
organization	x	x	x	x	x
project	x	x	x	x	x

पाइपलाइन

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
pipeline	x	x	x	x	x	run, retry
pipeline_v1 (अल्फा)	x	x	x	x	x	run
pipeline_dynamic_execution						run
execution	x	x				interrupt
execution_inputs		x
trigger	x	x	x	x	x
pipeline_summary		x
input_set	x	x	x	x	x
runtime_input_template		x
runtime_input_template_v1		x
pipeline_resolved_yaml		x
approval_instance	x					approve, reject

दोनों पाइपलाइन YAML संसाधन प्रकार उपलब्ध हैं जब पाइपलाइन टूलसेट सक्षम होता है। HARNESS_PIPELINE_VERSION और HTTP x-harness-pipeline-version आरंभीकरण हेडर डिफ़ॉल्ट संस्करण वरीयता का चयन करते हैं; वे दूसरे संस्करण को छिपाते नहीं हैं।

AI एजेंट

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
agent	x	x	x	x	x
agent_run	x

सेवाएँ

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
service	x	x	x	x	x

वातावरण

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
environment	x	x	x	x	x	move_configs

कनेक्टर

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
connector	x	x	x	x	x	test_connection
connector_catalogue	x

बुनियादी ढाँचा

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
infrastructure	x	x	x	x	x	move_configs

रहस्य

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
secret	x	x

निष्पादन लॉग

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
execution_log		x

ऑडिट ट्रेल

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
audit_event	x	x

प्रतिनिधि

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
delegate	x	x
delegate_token	x	x	x		x	revoke, get_delegates

कोड रिपॉजिटरी

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अपडेट करें	हटाएं	निष्पादन क्रियाएँ
repository	x	x	x	x
branch	x	x	x		x
commit	x	x	x			diff, diff_stats
file_content	x	x				blame
tag	x		x		x
repo_rule	x	x
space_rule	x	x

commit निर्माण क्लोनिंग के बिना सीधे Harness Code API के माध्यम से एक या अधिक फ़ाइल क्रियाएँ प्रतिबद्ध करता है। body.title, body.branch, और body.actions पास करें; प्रत्येक क्रिया CREATE, UPDATE, DELETE, या MOVE है, और UPDATE को वर्तमान ब्लॉब 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 फ़ाइल स्टोर फ़ाइलों और फ़ोल्डरों का प्रबंधन करता है। यह खाता, संगठन और प्रोजेक्ट स्कोप का समर्थन करता है; resource_scope="account"|"org"|"project" पास करें या Harness फ़ाइल स्टोर URL पेस्ट करें ताकि सर्वर स्कोप और ID प्राप्त कर सके।

सामान्य कॉल:

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

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

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

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

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

मल्टीपार्ट बॉडी बाधाएँ:

• बनाएं/अद्यतन JSON body स्वीकार करते हैं, फिर इसे /ng/api/file-store के लिए multipart/form-data में परिवर्तित करें।
• name, type (FILE या FOLDER), और parent_identifier आवश्यक हैं; चयनित स्कोप के रूट के लिए केवल शाब्दिक "Root" का उपयोग करें।
• FILE बनाने के लिए content (UTF-8 स्ट्रिंग) या content_base64 (मान्य गैर-रिक्त base64) में से ठीक एक की आवश्यकता होती है। FILE अद्यतन केवल मेटाडेटा-अद्यतन के लिए सामग्री को छोड़ सकता है, या सामग्री को बदलने के लिए ठीक एक सामग्री फ़ील्ड प्रदान कर सकता है।
• FOLDER बनाएं/अद्यतन को content और content_base64 को छोड़ना चाहिए।
• वैकल्पिक file_usage MANIFEST_FILE, CONFIG, या SCRIPT होना चाहिए; वैकल्पिक स्केलर मेटाडेटा जैसे description, mime_type, path, और tags स्ट्रिंग होना चाहिए।
• अपलोड सामग्री 100 MB तक सीमित है। पुष्टिकरण संकेत content, content_base64, और contentBase64 पूर्वावलोकन को पूछताछ से पहले संपादित करते हैं।

list_children या तो शॉर्टहैंड (resource_id प्लस params.folder_name, या params.file_store_id/params.folder_identifier प्लस params.folder_name) या identifier, name, और type: "FOLDER" के साथ पूर्ण FileStoreNode body स्वीकार करता है। पूर्ण बॉडी Harness camelCase parentIdentifier का उपयोग करती हैं; शॉर्टहैंड params.parent_identifier का उपयोग कर सकता है।

टेम्पलेट

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
template	x	x	x	x	x

टेम्पलेट संचालन Harness टेम्पलेट सेवा पथ (/template/api/templates...) का उपयोग करते हैं। बनाएं और अद्यतन के लिए body.template_yaml या body.yaml में पूर्ण टेम्पलेट YAML स्ट्रिंग की आवश्यकता होती है; version_label अद्यतन/हटाने के लिए एक विशिष्ट संस्करण को लक्षित करता है, जबकि version_label के बिना हटाना सभी संस्करणों को हटा देता है।

डैशबोर्ड

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
dashboard	x	x
dashboard_data		x

डेटाबेस DevOps

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
database_schema	x	x	x	x	x
database_instance	x	x	x	x	x
database_snapshot_object	x	x
database_llm_authoring_pipeline		x

कोड के रूप में अवसंरचना प्रबंधन (IaCM)

IaCM संसाधन डिफ़ॉल्ट रूप से सक्षम हैं और अधिकतर प्रोजेक्ट-स्कोप्ड हैं। वर्कस्पेस पहचानकर्ता खोजने के लिए iacm_workspace से शुरू करें, फिर वर्कस्पेस संसाधनों, लागतों और गतिविधि अंतरों के लिए उस workspace_id का उपयोग करें। खाता, संगठन या प्रोजेक्ट स्कोप पर पुन: प्रयोज्य चर सेट के लिए iacm_variable_set का उपयोग करें। प्रदाता रजिस्ट्री खाता-स्कोप्ड है।

iacm_module खाता, संगठन और प्रोजेक्ट स्कोप में फैला हुआ है। यह डिफ़ॉल्ट रूप से खाता रजिस्ट्री का उपयोग करता है; प्रत्येक संचालन (सूची, प्राप्त करें, बनाएं, अद्यतन) समान scope_org / scope_project क्वेरी पैरामीटर भेजता है, इसलिए आपके द्वारा बनाया गया मॉड्यूल उस स्कोप पर खोजा जा सकता है जहाँ आपने इसे बनाया था। resource_scope="account" | "org" | "project" प्लस org_id/project_id के साथ स्कोप चुनें। स्कोपिंग ऑप्ट-इन है: जब resource_scope छोड़ दिया जाता है, org_id/project_id केवल तभी लागू होते हैं जब आप उन्हें स्पष्ट रूप से पास करते हैं — कॉन्फ़िगर किए गए HARNESS_ORG/HARNESS_PROJECT डिफ़ॉल्ट लागू नहीं होते हैं, इसलिए एक परिवेश प्रोजेक्ट कॉन्फ़िगरेशन चुपचाप प्रोजेक्ट के तहत खाता मॉड्यूल पंजीकृत नहीं कर सकता है। मॉड्यूल बॉडी के अपने org/project फ़ील्ड इसके Git कनेक्टर का पता लगाते हैं और इस दृश्यता स्कोप से असंबंधित हैं।

iacm_workspace बनाएं/अद्यतन केवल { policy_evaluation } लौटाते हैं — वर्कस्पेस प्राप्त करने के लिए harness_get के साथ अनुवर्ती करें। iacm_variable_set और iacm_module बनाएं/अद्यतन संसाधन स्वयं लौटाते हैं। iacm_provider बनाना केवल { id } लौटाता है — harness_get के साथ अनुवर्ती करें; अद्यतन केवल संस्करण-उन्मुख है (POST/PUT /providers/{id}/version) — कोई मेटाडेटा PUT नहीं है। संस्करण लेखन खाली बॉडी लौटा सकता है; HarnessClient इसे { status: "SUCCESS", message: "No content" } में सामान्यीकृत करता है।

चर-सेट अद्यतन HTTP PUT है जिसमें पूर्ण-प्रतिस्थापन संग्रह हैं — हमेशा पहले harness_get करें, फिर पूर्ण वांछित बॉडी PUT करें (अद्यतन पर terraform_variables / environment_variables आवश्यक हैं; छोड़ें/खाली कनेक्टर और चर फ़ाइलों को साफ़ करता है)। मॉड्यूल अद्यतन भी PUT है — वैकल्पिक फ़ील्ड के लिए get-then-put पसंद करें। लेखन medium_write हैं और पुष्टिकरण की आवश्यकता होती है (पूछताछ या confirm: true)।

चर-सेट और प्रदाता-रजिस्ट्री RBAC (iac_variableset_*, iac_providerregistry_*) वर्तमान में Harness में प्रयोगात्मक हैं — एक्सेस जाँच हमेशा अनुमति देती हैं जब तक iac-server प्रवर्तन सक्षम नहीं करता। मॉड्यूल रजिस्ट्री RBAC (iac_registry_view / iac_registry_edit) सक्रिय और प्रवर्तनीय है। MCP हमेशा कॉलर PAT/SAT को अपरिवर्तित अग्रेषित करता है।

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
iacm_workspace	x	x	x	x
iacm_variable_set	x	x	x	x
iacm_resource	x
iacm_module	x	x	x	x
iacm_provider	x	x	x	x
iacm_workspace_costs	x
iacm_activity_resource_change	x

विशिष्ट कार्यप्रवाह:

1. वर्कस्पेस खोजने के लिए harness_list(resource_type="iacm_workspace", org_id="...", project_id="...")।
2. खरोंच से या टेम्पलेट से बनाने के लिए iacm_workspace पर harness_create / harness_update (associated_template), या मौजूदा वर्कस्पेस को अद्यतन करें — प्रतिक्रिया केवल { policy_evaluation } है।
3. बनाए गए/अद्यतन किए गए वर्कस्पेस को प्राप्त करने के लिए harness_get(resource_type="iacm_workspace", workspace_id="...")।
4. पुन: प्रयोज्य Terraform/env चर सेट के लिए iacm_variable_set पर harness_list / harness_create / harness_update (वैकल्पिक रूप से resource_scope के साथ) — प्रतिक्रिया VariableSet संसाधन है।
5. मॉड्यूल रजिस्ट्री के लिए iacm_module पर harness_list / harness_create / harness_update (name + system आवश्यक हैं; संगठन- या प्रोजेक्ट-स्कोप्ड मॉड्यूल के लिए org_id/project_id के साथ resource_scope जोड़ें) — प्रतिक्रिया मॉड्यूल संसाधन है।
6. खाता प्रदाता रजिस्ट्री के लिए iacm_provider पर harness_list / harness_create / harness_update (बनाने के लिए body.type आवश्यक है; बनाना केवल { id } लौटाता है — फिर harness_get; अद्यतन केवल संस्करण बनाता/अद्यतन करता है) — संस्करण अद्यतन खाली सफलता लौटा सकता है।
7. Terraform संसाधनों, आउटपुट और डेटा स्रोतों का निरीक्षण करने के लिए harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...")।
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-आधारित पृष्ठ का अनुरोध करते रहें और यदि आपको कुल की आवश्यकता है तो पृष्ठ गणनाएँ जोड़ें।

आंतरिक डेवलपर पोर्टल (IDP)

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
idp_entity	x	x
scorecard	x	x
scorecard_check	x	x
scorecard_stats		x
scorecard_check_stats		x
idp_score	x	x
idp_workflow	x					execute
idp_tech_doc	x

पुल अनुरोध

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
pull_request	x	x	x	x		close, merge
pr_reviewer	x		x			submit_review
pr_comment			x	x	x
pr_check	x
pr_activity	x

स्पष्ट बंद संचालन के लिए harness_execute(resource_type="pull_request", action="close", ...) का उपयोग करें। harness_update भी body.state (open या closed) स्वीकार करता है और समर्पित Harness Code PR स्थिति समापन बिंदु पर स्थिति परिवर्तनों को रूट करता है; शीर्षक/विवरण संपादन एक अलग अद्यतन कॉल में भेजें।

PR टिप्पणियाँ पढ़ने के लिए harness_list(resource_type="pr_activity", filters={type: ["comment", "code-comment"]}, ...) का उपयोग करें। टिप्पणी लेखन संचालन के लिए pr_comment का उपयोग करें।

रिलीज़ प्रबंधन

रिलीज़ प्रबंधन (RMG) संसाधन डिफ़ॉल्ट रूप से सक्षम हैं। परिभाषा संसाधन (release_process, release_activity) body.yaml के साथ सूची/प्राप्त करें/बनाएं/अद्यतन/हटाएं का समर्थन करते हैं; बनाएं/अद्यतन से पहले harness_schema(resource_type="release_process"|"release_activity") कॉल करें। निष्पादन संसाधन चल रहे रिलीज़ की निगरानी करते हैं — अधिकांश सूची संचालन के लिए release_id की आवश्यकता होती है (harness_list resource_type=release से UUID, या UI URL स्लग जैसे identifier-1.0.0-abc)। RMG रिलीज़ URL को harness_list में पेस्ट करें ताकि release_id स्वतः भर जाए।

RMG कॉल Harness-Account हेडर के माध्यम से खाता स्कोपिंग के साथ ${HARNESS_BASE_URL}/gateway/rmg का उपयोग करते हैं। संगठन/प्रोजेक्ट स्कोप हेडर-आधारित स्कोपिंग का उपयोग करता है जब org_id/project_id प्रदान किए जाते हैं। release_execution_phase केवल-सूची है — चरण इनपुट/आउटपुट संसाधनों पर harness_get कॉल करते समय प्रत्येक चरण आइटम के identifier फ़ील्ड को params.phase_identifier के रूप में उपयोग करें (release_execution_phase पर ही harness_get कॉल न करें)। रिलीज़ सूची status फ़िल्टरिंग केवल वर्तमान पृष्ठ पर क्लाइंट-साइड लागू की जाती है; जब परिणाम पृष्ठों में फैल सकते हैं तो समान फ़िल्टर के साथ पृष्ठांकन जारी रखें।

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
release_process	x	x	x	x	x
release_activity	x	x	x	x	x
release	x	x
release_execution_phase	x
release_execution_task	x
release_execution_activity	x
release_input		x
release_execution_phase_input		x
release_execution_phase_output		x
release_execution_activity_input		x
release_execution_activity_output		x

विशिष्ट कार्यप्रवाह:

1. ऑर्केस्ट्रेशन प्रक्रिया परिभाषाओं की खोज के लिए harness_list(resource_type="release_process", org_id="...", project_id="...")।
2. बनाने/अद्यतन करने से पहले harness_schema(resource_type="release_process") (या release_activity); फिर body.yaml के साथ harness_create / harness_update।
3. सक्रिय या हाल की रिलीज़ खोजने के लिए harness_list(resource_type="release", org_id="...", project_id="...") (डिफ़ॉल्ट 30-दिन का पूर्वावलोकन; वैकल्पिक filters.status, filters.search_term, filters.days_back)।
4. रिलीज़ विवरण के लिए harness_get(resource_type="release", release_id="...")।
5. चरण स्थिति के लिए harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }); release_execution_task और release_execution_activity के लिए समान release_id।
6. release_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 का उपयोग करके harness_get, जैसा कि प्रत्येक संसाधन पर प्रलेखित है।

वाइब

डिफ़ॉल्ट-सक्षम vibe टूलसेट ${HARNESS_BASE_URL}/vibe/v1 के अंतर्गत वाइब ऑर्केस्ट्रेटर BFF अनुबंध को कवर करता है। यह मौजूदा Harness कनेक्शन और खाता हेडर का उपयोग करता है, बिना अनुरोध निकायों में खाता/संगठन/प्रोजेक्ट क्वेरी पैरामीटर या स्कोप फ़ील्ड जोड़े। टीम ने Harness API-कुंजी प्रमाणीकरण (PAT/SAT) का उपयोग करके वाइब प्रवाह को मान्य किया, इसलिए डिफ़ॉल्ट सत्रों के लिए कोई ऑप्ट-इन सेटिंग आवश्यक नहीं है। क्यूरेटेड OpenAPI दस्तावेज़ बियरर/सत्र प्रमाणीकरण; सर्वर का OAuth मोड वर्तमान सत्र के बियरर टोकन को आगे भेजता है। स्वचालित प्रतिगमन दोनों हेडर पथों को सत्यापित करते हैं; गेटवे प्रमाणीकरण लक्ष्य वातावरण के कॉन्फ़िगरेशन के अधीन रहता है।

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
vibe_project			x			prepare, deploy
vibe_app_lifecycle		x				events

API दो इनटेक पथों का समर्थन करता है। इन API-मूल अनुरोध आकृतियों को बनाए रखें:

कोडिंग एजेंट के लिए उपलब्ध स्रोत	API प्रवाह
GitHub रिपॉजिटरी लिंक/कनेक्टर	resource_type="vibe_project" और body.mode के साथ harness_create के साथ-साथ मोड-विशिष्ट फ़ील्ड। अनुबंध github_link और github_connector नाम देता है लेकिन उनके URL, शाखा, या कनेक्टर फ़ील्ड आकृतियों को परिभाषित नहीं करता है; ये फ़ील्ड मैपिंग का आविष्कार किए बिना बैकएंड को अग्रेषित किए जाते हैं।
ZIP फ़ाइल	ऐप नाम और फ़ाइल मेटाडेटा के साथ prepare को कॉल करें, लौटाए गए हस्ताक्षरित लक्ष्य पर बाइट्स अपलोड करें, फिर deploy को कॉल करें।
स्थानीय स्रोत निर्देशिका	कोडिंग एजेंट इच्छित कार्यक्षेत्र स्रोत को स्थानीय रूप से ZIP में संग्रहीत करता है, फिर ZIP प्रवाह का पालन करता है। स्थानीय पथ या संवादात्मक संदर्भ API-समर्थित स्रोत अपलोड नहीं है।

किसी निर्देशिका को पैकेज करते समय, इसे बनाने के लिए आवश्यक स्रोत, मैनिफेस्ट, लॉकफ़ाइल, कॉन्फ़िगरेशन और इच्छित अप्रतिबद्ध संपादन शामिल करें। क्रेडेंशियल, .git, स्थापित निर्भरताएँ और उत्पन्न कलाकृतियाँ बाहर करें। पैकेजिंग और हस्ताक्षरित अपलोड वहाँ होते हैं जहाँ फ़ाइलें सुलभ होती हैं; एक होस्टेड MCP सर्वर कोडिंग एजेंट की स्थानीय निर्देशिका नहीं पढ़ सकता है।

मौजूदा ZIP के लिए, अपलोड तैयार करें:

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

इसे harness_execute को पास करें। आकार वास्तविक ZIP का वर्णन करना चाहिए; size_bytes, content_type, और md5 वैकल्पिक और शून्य-योग्य हैं। अतिरिक्त तैयारी फ़ील्ड बैकएंड सत्यापन के लिए संरक्षित हैं, जैसा कि OpenAPI द्वारा अनुमति है। तैयारी projectId, sourceId, और upload लौटाती है, जिसमें प्रत्येक फ़ाइल का uploadUrl, method, headers, और expiresAt शामिल है। उस हस्ताक्षरित URL, विधि और हेडर का उपयोग करके फ़ाइल बाइट्स सीधे अपलोड करें; URL को बिल्कुल संरक्षित रखें और स्टोरेज अनुरोध में Harness क्रेडेंशियल न जोड़ें। तैयारी क्रिया स्थानीय फ़ाइलों को पढ़ती या अपलोड नहीं करती है।

सफल अपलोड के बाद, स्पष्ट रूप से तैनात करें:

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

JSON आयात के लिए, लौटाए गए id का उपयोग करें। तैनाती body: {"project_id": "<Vibe app id>"} या params.app_id भी स्वीकार करती है; API वायर फ़ील्ड snake_case project_id है, भले ही तैयारी camelCase projectId लौटाती है। सामान्य टूल का शीर्ष-स्तरीय project_id एक Harness स्कोप पहचानकर्ता है और इसे कभी भी वाइब ऐप आईडी के रूप में उपयोग नहीं किया जाता है। आयात और तैयारी ऐप/स्रोत बनाते हैं; कोई भी तैनाती शुरू नहीं करता है। लेखन स्वचालित रूप से पुनः प्रयास नहीं किए जाते हैं, और तैनाती मौजूदा उच्च-जोखिम पुष्टिकरण नीति का उपयोग करती है।

harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>") के साथ प्रगति पढ़ें। यह ऐप URL, निष्पादन चरण, उप-चरण, विफलताएँ, लॉग लाइनें और बिल्ड-विश्लेषक विवरण बनाए रखता है। events निष्पादन क्रिया resource_id या params.app_id स्वीकार करती है और SSE एंडपॉइंट को एक सीमित बैच के रूप में उपभोग करती है: कनेक्शन के बाद अधिकतम 20 JSON इवेंट या पाँच सेकंड, 1 MiB प्रतिक्रिया सीमा के साथ। ये सीमाएँ वाइब एंडपॉइंट की हैं। कनेक्शन का HARNESS_API_TIMEOUT_MS कनेक्शन और स्ट्रीम उपभोग दोनों को एक साथ सीमित करता है; समाप्ति एक टाइमआउट त्रुटि लौटाती है। एक पूर्ण बैच events और stop_reason (end, event_limit, या duration_limit) लौटाता है और स्ट्रीम बंद करता है। न तो प्रारंभिक कनेक्शन विफलताएँ और न ही टूटी स्ट्रीम पुनः प्रयास की जाती हैं। इवेंट क्षणिक अंतर हैं जिनमें कोई प्रलेखित रीप्ले कर्सर नहीं है; प्राधिकृत स्नैपशॉट के लिए जीवनचक्र प्राप्त करें का उपयोग करें। दोनों जीवनचक्र रीड केवल-पढ़ने के मोड में उपलब्ध हैं।

फीचर फ्लैग

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
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 एक साथ पास करते हैं और Harness-मूल एंडपॉइंट (मानक HARNESS_API_KEY/HARNESS_BASE_URL, हर अन्य harness_* संसाधन के समान प्रमाणीकरण) को हिट करते हैं। एक ही कॉल पर workspace_id और org_id/project_id दोनों पास करना, या org_id को अकेले project_id के साथ मिलाना, एक त्रुटि है — प्रति कॉल एक मोड चुनें। नीचे दिया गया प्रत्येक ऑपरेशन विरासत मोड में उपलब्ध है, अपरिवर्तित, जब तक कि संसाधन को केवल Harness-मूल के रूप में चिह्नित नहीं किया गया हो। Harness-मूल मोड कवरेज वर्तमान में संकीर्ण है:

• fme_workspace — Harness का कोई मूल समकक्ष नहीं; केवल लीगेसी-मोड (workspace_id मान खोजने के लिए उपयोग किया जाता है)।

• fme_environment — द्वि-मोड list (workspace_id या org_id+project_id)। get/create/update/delete केवल Harness-मूल हैं (/fme/api/v4/environments) — MCP के पास उन ऑपरेशनों के लिए कभी workspace_id अनुबंध नहीं था। मूल सूची वैकल्पिक offset/limit का उपयोग करती है (अधिकतम 100; harness_list size limit पर मैप होता है); लिफाफा {data, limit, offset, totalCount} को items/total में प्रचारित किया जाता है। मूल निर्माण/अद्यतन isProduction का उपयोग करते हैं (production को उपनाम के रूप में स्वीकार किया जाता है)। मूल अद्यतन JSON मर्ज पैच है; name और isProduction साफ़ करने योग्य नहीं हैं। नाम अधिकतम 15 वर्ण।

• fme_feature_flag — द्वि-मोड, दोनों शाखाएँ पूरी तरह से जुड़ी हुई हैं। Harness-मूल (org_id+project_id): list/get/create/delete /fme/api/v4/feature-flags को हिट करते हैं (create के लिए बॉडी: name, trafficType, वैकल्पिक description/tags/owners, प्रति CreateFeatureFlagRequest); update /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 के साथ क्वेरी पैरामीटर के रूप में हिट करते हैं (वैकल्पिक comment/title, प्रति FeatureFlagDefinitionActionRequest)।

• fme_feature_flag_definition — get/create/update द्वि-मोड बने रहते हैं (workspace_id या org_id+project_id)। list/delete/kill/restore/reallocate केवल Harness-मूल हैं (org_id+project_id) — MCP के पास उन ऑपरेशनों के लिए कभी workspace_id अनुबंध नहीं था। मूल सूची के लिए feature_flag_name आवश्यक है और offset/limit का उपयोग करती है (डिफ़ॉल्ट 100, अधिकतम 100); यह environment_id नहीं लेती। हटाने और निष्पादित करने के लिए environment_id आवश्यक है। किल/रीस्टोर/रीअलोकेट fme_feature_flag पर समान क्रियाएँ हैं। प्राप्त/निर्माण/अद्यतन बॉडी लीगेसी से मेल खाती है (treatments, defaultTreatment, defaultRule, वैकल्पिक rules/baselineTreatment/trafficAllocation/comment), साथ ही Harness-मूल मोड में वैकल्पिक title। मूल अद्यतन JSON मर्ज पैच है।

• 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-मूल मोड हर ऑपरेशन पर अस्वीकार कर दिया जाता है (list/get/create/delete) — इसके बजाय fme_segment का उपयोग करें; यह संसाधन केवल लीगेसी workspace_id अनुबंध का समर्थन करता है।

• fme_rule_based_segment_definition — (पदावनत — fme_segment_definition देखें।) Harness-मूल मोड हर ऑपरेशन/क्रिया पर अस्वीकार कर दिया जाता है (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-मूल अस्वीकार कर दिया गया है — fme_segment का उपयोग करें।

• fme_segment_keys — list/update लीगेसी बने रहते हैं (workspace_id / environment_id+segment_name)। Harness-मूल (org_id+project_id) अस्वीकार कर दिया गया है — fme_segment_definition निष्पादित list_keys/add_keys/remove_keys का उपयोग करें।

• fme_segment — केवल मूल (org_id+project_id)। CRUD। list/get/update/delete के लिए segment_type आवश्यक है: STANDARD | LARGE | RULE_BASED। निर्माण बॉडी: name, trafficType, segmentType; वैकल्पिक description, tags, owners।

• fme_segment_definition — केवल मूल। CRUD के साथ-साथ निष्पादित list_keys/add_keys/remove_keys। अद्यतन केवल विवरण है। कुंजियाँ शेष रहते हुए हटाना hasDependents के साथ विफल होता है।

• fme_metric — केवल Harness-मूल (कोई लीगेसी workspace_id समर्थन नहीं)। list/get/create/update/delete /fme/api/v4/metrics से जुड़े हैं (list का harness_list size limit पर मैप होता है)। create के लिए spread आवश्यक है, भले ही बैकएंड CreateMetricRequest इसे वैकल्पिक रखता है (डिफ़ॉल्ट PER) — केवल MCP-पक्ष का सख्त अनुबंध, क्योंकि इसे छोड़ने से RATE मीट्रिक के अर्थ में चुपचाप परिवर्तन होता है। update JSON मर्ज पैच है; name/trafficType अपरिवर्तनीय हैं और स्वीकार नहीं किए जाते। delete एक स्थायी हार्ड डिलीट है (कोई संग्रह/पुनर्स्थापना नहीं) — destructive के रूप में वर्गीकृत।

• fme_event_type — केवल Harness-मूल (कोई लीगेसी workspace_id समर्थन नहीं)। केवल-पठन: list/get /fme/api/v4/event-types से जुड़े हैं; id इवेंट नाम है। केवल उन इवेंट प्रकारों को देखा जा सकता है जिनमें पिछले 30 दिनों में इवेंट हैं; get अनुरोध करने वाले वर्कस्पेस के ट्रैफ़िक-प्रकार दायरे से बाहर के इवेंट प्रकार के लिए, या 30 दिनों से अधिक निष्क्रिय होने पर 404 लौटाता है। सूची फ़िल्टर: name (सबस्ट्रिंग), traffic_type (आईडी या नाम से), offset/limit (harness_list size limit पर मैप होता है)। fme_metric के baseEventTypes/filterEventType या event_type_ids फ़िल्टर में किसी का संदर्भ देने से पहले वास्तविक इवेंट प्रकार आईडी खोजने के लिए इसका उपयोग करें, आईडी का अनुमान लगाने के बजाय।

एकल-उपयोगकर्ता/स्व-होस्टेड मोड में, लीगेसी-मोड प्रमाणीकरण HARNESS_FME_API_KEY से Bearer टोकन का उपयोग करता है, गैर-प्लेसहोल्डर HARNESS_API_KEY पर वापस गिरता है। HARNESS_FME_API_KEY एक लीगेसी Split एडमिन कुंजी या FME-अधिकृत Harness PAT/SAT हो सकता है, लेकिन इसे multi-user मोड में अस्वीकार कर दिया जाता है ताकि साझा तैनाती प्रत्येक सत्र उपयोगकर्ता के क्रेडेंशियल को ओवरराइड न कर सके। Harness प्लेटफ़ॉर्म API के लिए होस्टेड OAuth/सेवा-रूटिंग क्रेडेंशियल सीधे Split.io अनुरोधों को प्रमाणित नहीं करते। fme_feature_flag लीगेसी मोड में पूर्ण जीवनचक्र प्रबंधन का समर्थन करता है: निर्माण (traffic_type_id आवश्यक है), सूची, प्राप्त, मेटाडेटा अद्यतन, हटाना, और किल/रीस्टोर/रीअलोकेट/आर्काइव/अनआर्काइव निष्पादित क्रियाएँ। ट्रैफ़िक प्रकार आईडी खोजने के लिए fme_traffic_type का उपयोग करें, पहचान विशेषताएँ बनाने/अद्यतन करने के लिए fme_identity, और मानक सेगमेंट का निरीक्षण करने और सदस्य कुंजियाँ जोड़ने के लिए fme_standard_segment / fme_segment_keys का उपयोग करें। fme_rule_based_segment लक्ष्यीकरण सेगमेंट के लिए CRUD प्रदान करता है, जबकि fme_rule_based_segment_definition सक्षम/अक्षम और परिवर्तन अनुरोध अनुमोदन प्रवाह के साथ पर्यावरण-विशिष्ट सेगमेंट नियमों का प्रबंधन करता है।

GitOps

संसाधन प्रकार	सूची	प्राप्त	निर्माण	अद्यतन	हटाना	निष्पादित क्रियाएँ
gitops_agent	x	x
gitops_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_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)

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
cost_perspective	x	x	x	x	x
cost_breakdown	x
cost_timeseries	x
cost_summary	x	x
cost_recommendation	x	x				update_state, override_savings, create_jira_ticket, create_snow_ticket
cost_anomaly	x
cost_anomaly_summary		x
cost_category	x	x
cost_account_overview		x
cost_filter_value	x
cost_recommendation_stats		x
cost_recommendation_detail		x
cost_commitment		x
ai_budget	x	x	x	x	x
ai_budget_overview		x
ai_budget_consumption	x
ai_budget_override_request	x	x	x			approve, reject

सॉफ्टवेयर इंजीनियरिंग इनसाइट्स (SEI)

SEI संसाधनों को टोकन दक्षता के लिए समेकित किया गया है। DORA, टीम/संगठन-वृक्ष विवरण, और AI इनसाइट्स के लिए metric या aspect पैरामीटर का उपयोग करें।

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
sei_metric	x
sei_productivity_metric		x
sei_dora_metric		x				metric पास करें: deployment_frequency, change_failure_rate, mttr, lead_time, या *_drilldown
sei_team	x	x
sei_team_detail	x					aspect पास करें: integrations, developers, integration_filters
sei_org_tree	x	x
sei_org_tree_detail	x	x				aspect पास करें: efficiency_profile, productivity_profile, business_alignment_profile, integrations, teams
sei_business_alignment	x	x				प्राप्त करने के लिए aspect पास करें: feature_metrics, feature_summary, 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

एविडेंस वॉल्ट

एविडेंस वॉल्ट in-toto प्रमाणपत्र (SDLC साक्ष्य) संग्रहीत करता है। सूची resource_scope के माध्यम से खाता/संगठन/परियोजना स्कोप का समर्थन करती है। एकल मुक्त-पाठ फ़िल्टर (पाइपलाइन, अकेले आर्टिफैक्ट, gitoid) search_term का उपयोग करते हैं; एक अतिरिक्त नाम बाधा filters.subject_name का उपयोग करती है; विषय सामग्री डाइजेस्ट filters.subject_digest का उपयोग करता है। प्राप्त करें gitoid_sha256 द्वारा खोजता है और org_id/project_id (सूची पंक्ति से) की आवश्यकता होती है। डाउनलोड (harness_execute क्रिया download) एक समय-सीमित download_url लौटाता है — उस लिंक को हमेशा उपयोगकर्ता को दिखाएं। फीचर फ्लैग SCS_EVIDENCE_VAULT की आवश्यकता है।

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
attestation	x	x				download

सुरक्षा परीक्षण ऑर्केस्ट्रेशन (STO)

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
security_issue	x
security_issue_filter	x
security_exemption	x		x			approve, reject
remediation_diff	x

security_exemption बनाना एक high_write ऑपरेशन है। सर्वर प्रमाणित PAT से requester_id प्राप्त करता है, exemptFutureOccurrences=true सेट करता है, और प्रदान नहीं होने पर duration_days को 30 पर डिफ़ॉल्ट करता है। छूट सूचीबद्ध करने के लिए, एक छोटा स्पष्ट पृष्ठ आकार पास करें (उदाहरण के लिए filters: { "status": "Pending", "size": 5 }) और प्रत्येक प्रतिक्रिया में लौटाए गए _nextPageHint का पालन करें।

सुरक्षा छूट निष्पादन कार्यप्रवाह:

• harness_list का उपयोग resource_type="security_exemption" और एक स्पष्ट status जैसे Pending, Approved, Rejected, Expired, या Canceled के साथ करें।
• harness_execute का उपयोग action="approve" और एक आवश्यक body.scope के साथ करें: CURRENT, ACCOUNT, ORG, या PROJECT। CURRENT छूट के मौजूदा स्कोप पर अनुमोदन करता है; अन्य स्कोप आंतरिक रूप से STO प्रमोट एंडपॉइंट का उपयोग करते हैं। सर्वर छोड़े जाने पर प्रमाणित उपयोगकर्ता से body.approver_id स्वतः भरता है; body.comment वैकल्पिक है।
• छूट अस्वीकार करने के लिए action="reject" का उपयोग करें। छोड़े जाने पर body.approver_id भी स्वतः भरा जाता है।
• कोई अलग promote निष्पादन क्रिया नहीं है। जब अनुरोधित परिणाम खाता, संगठन, या परियोजना स्कोप पर अनुमोदन हो, तो गैर-CURRENT body.scope के साथ action="approve" का उपयोग करें।

एक्सेस नियंत्रण

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
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

शासन

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
policy	x	x	x	x	x
policy_set	x	x	x	x	x
policy_evaluation	x	x

परिनियोजन फ्रीज़

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
freeze_window	x	x	x	x	x	toggle_status
global_freeze		x				manage

सेवा ओवरराइड

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
service_override	x	x	x	x	x

सेटिंग्स

संसाधन प्रकार	सूची	प्राप्त करें	बनाएं	अद्यतन करें	हटाएं	क्रियाएँ निष्पादित करें
setting	x

MCP प्रॉम्प्ट

DevOps

Prompt	Description	Parameters
build-deploy-app	एंड-टू-एंड CI/CD वर्कफ़्लो: git रिपॉजिटरी स्कैन करें, CI पाइपलाइन जनरेट करें (build & push Docker image), K8s मैनिफेस्ट खोजें या जनरेट करें, CD पाइपलाइन बनाएं, और डिप्लॉय करें — CI विफलताओं पर स्वतः पुनः प्रयास (अधिकतम 5 प्रयास) और CD विफलताओं पर (उपयोगकर्ता अनुमति के साथ अधिकतम 3 प्रयास) के साथ। पुनः प्रयास समाप्त होने पर, मैन्युअल जांच के लिए सभी बनाए गए संसाधनों के Harness UI डीप लिंक प्रदान करता है।	repoUrl (आवश्यक), imageName (आवश्यक), projectId (वैकल्पिक), namespace (वैकल्पिक)
debug-pipeline-failure	विफल निष्पादन का विश्लेषण करें: एक execution ID, pipeline ID, या Harness URL स्वीकार करता है। harness_diagnose के माध्यम से stage/step विवरण, विफलता विवरण, delegate जानकारी, और विफल step लॉग प्राप्त करता है, फिर root cause विश्लेषण और सुझाए गए सुधार प्रदान करता है। स्वचालित रूप से श्रृंखलाबद्ध पाइपलाइन विफलताओं का अनुसरण करता है।	executionId (वैकल्पिक), projectId (वैकल्पिक)
pipeline_summarizer	पाइपलाइन निष्पादन से सभी step लॉग प्राप्त करें और सारांशित करें। harness_diagnose का उपयोग include_logs: true, include_all_step_logs: true के साथ करके हर step का लॉग प्राप्त करता है, फिर Step Name, Status, Duration, और What Happened (लॉग-आधारित सारांश) के साथ एक तालिका प्रस्तुत करता है। किसी भी step को छोड़ता नहीं है।	executionId (वैकल्पिक), projectId (वैकल्पिक)
create-pipeline	प्राकृतिक भाषा आवश्यकताओं से एक नई पाइपलाइन YAML जनरेट करें, संदर्भ के लिए मौजूदा संसाधनों की समीक्षा करते हुए	description (आवश्यक), projectId (वैकल्पिक)
create-agent	इंटरैक्टिव रूप से एक Harness AI एजेंट बनाएं — मौजूदा एजेंटों की जाँच करें (अपडेट करते समय वर्तमान agent.uses बनाम विरासत agent.step.group.steps spec प्रारूप का पता लगाएं), आवश्यकताएँ एकत्र करें, उपयुक्त प्रारूप में एजेंट spec जनरेट करें, उपयोगकर्ता से पुष्टि करें, फिर harness_create/harness_update के माध्यम से बनाएं या अपडेट करें	agent_name (आवश्यक), task_description (आवश्यक), org_id (वैकल्पिक), project_id (वैकल्पिक)
onboard-service	परिवेशों और एक डिप्लॉयमेंट पाइपलाइन के साथ एक नई सेवा को ऑनबोर्ड करने की प्रक्रिया से गुजरें	serviceName (आवश्यक), projectId (वैकल्पिक)
dora-metrics-review	DORA मेट्रिक्स की समीक्षा करें (डिप्लॉयमेंट आवृत्ति, परिवर्तन विफलता दर, MTTR, लीड समय) Elite/High/Medium/Low वर्गीकरण और सुधार अनुशंसाओं के साथ	teamRefId (वैकल्पिक), dateStart (वैकल्पिक), dateEnd (वैकल्पिक)
setup-gitops-application	एक GitOps एप्लिकेशन को ऑनबोर्ड करने के माध्यम से मार्गदर्शन करें — एजेंट, क्लस्टर, रिपॉजिटरी सत्यापित करें, और एप्लिकेशन बनाएं	agentId (आवश्यक), projectId (वैकल्पिक)
chaos-resilience-test	सेवा लचीलापन परीक्षण के लिए एक chaos प्रयोग डिज़ाइन करें, fault injection, probes, और अपेक्षित परिणामों के साथ	serviceName (आवश्यक), projectId (वैकल्पिक)
feature-flag-rollout	सुरक्षा गेट्स के साथ परिवेशों में एक प्रगतिशील feature flag रोलआउट की योजना बनाएं और निष्पादित करें	flagIdentifier (आवश्यक), projectId (वैकल्पिक)
migrate-pipeline-to-template	मौजूदा पाइपलाइन का विश्लेषण करें और उसमें से पुन: उपयोग योग्य stage/step टेम्पलेट निकालें	pipelineId (आवश्यक), projectId (वैकल्पिक)
delegate-health-check	Delegate कनेक्टिविटी, स्वास्थ्य, टोकन स्थिति की जाँच करें, और बुनियादी ढांचे की समस्याओं का निवारण करें	projectId (वैकल्पिक)
developer-portal-scorecard	सेवाओं के लिए IDP स्कोरकार्ड की समीक्षा करें और डेवलपर अनुभव बेहतर बनाने के लिए अंतराल की पहचान करें	projectId (वैकल्पिक)
pending-approvals	अनुमोदन की प्रतीक्षा कर रहे पाइपलाइन निष्पादन खोजें, विवरण दिखाएं, और अनुमोदित या अस्वीकार करने की पेशकश करें	projectId (वैकल्पिक), orgId (वैकल्पिक), pipelineId (वैकल्पिक)

FinOps

Prompt	Description	Parameters
optimize-costs	क्लाउड लागत डेटा का विश्लेषण करें, संभावित बचत के आधार पर प्राथमिकता वाली अनुशंसाएँ और विसंगतियाँ सतह पर लाएं	projectId (वैकल्पिक)
cloud-cost-breakdown	सेवा, परिवेश, या क्लस्टर द्वारा क्लाउड लागतों में गहराई से जाएं, रुझान विश्लेषण और विसंगति पहचान के साथ	perspectiveId (वैकल्पिक), projectId (वैकल्पिक)
commitment-utilization-review	आरक्षित इंस्टेंस और बचत योजना उपयोग का विश्लेषण करें, अपशिष्ट खोजें और प्रतिबद्धताओं को अनुकूलित करें	projectId (वैकल्पिक)
cost-anomaly-investigation	लागत विसंगतियों की जाँच करें — मूल कारण, प्रभावित संसाधन, और सुधार निर्धारित करें	projectId (वैकल्पिक)
rightsizing-recommendations	राइटसाइज़िंग अनुशंसाओं की समीक्षा और प्राथमिकता दें, वैकल्पिक रूप से Jira या ServiceNow टिकट बनाएं	projectId (वैकल्पिक), minSavings (वैकल्पिक)

DevSecOps

Prompt	Description	Parameters
security-review	Harness संसाधनों में सुरक्षा मुद्दों की समीक्षा करें और गंभीरता के अनुसार सुधार सुझाएं	projectId (वैकल्पिक), severity (वैकल्पिक, डिफ़ॉल्ट: critical,high)
vulnerability-triage	पाइपलाइनों और आर्टिफैक्ट्स में सुरक्षा कमजोरियों की ट्रायेज करें, गंभीरता और शोषण क्षमता के आधार पर प्राथमिकता दें	projectId (वैकल्पिक), severity (वैकल्पिक)
sbom-compliance-check	आर्टिफैक्ट्स के लिए SBOM और अनुपालन स्थिति का ऑडिट करें — लाइसेंस जोखिम, नीति उल्लंघन, घटक कमजोरियाँ	artifactId (वैकल्पिक), projectId (वैकल्पिक)
supply-chain-audit	एंड-टू-एंड सॉफ्टवेयर आपूर्ति श्रृंखला सुरक्षा ऑडिट — उत्पत्ति, custody की श्रृंखला, नीति अनुपालन	projectId (वैकल्पिक)
security-exemption-review	लंबित सुरक्षा छूटों की समीक्षा करें और बैच अनुमोदन या अस्वीकृति निर्णय लें	projectId (वैकल्पिक)
bulk-exemption-create	स्पष्ट दायरे और अवधि मार्गदर्शन के साथ कई STO मुद्दों के लिए उचित सुरक्षा छूट बनाएं	projectId (आवश्यक), exemption_type (आवश्यक), reason (आवश्यक), issue फ़िल्टर (वैकल्पिक)
access-control-audit	उपयोगकर्ता अनुमतियों, अति-विशेषाधिकार प्राप्त खातों, और भूमिका असाइनमेंट का ऑडिट करें, न्यूनतम-विशेषाधिकार लागू करने के लिए	projectId (वैकल्पिक), orgId (वैकल्पिक)

Harness Code

प्रॉम्प्ट	विवरण	पैरामीटर
code-review	पुल रिक्वेस्ट की समीक्षा करें — डिफ, कमिट, जांच और टिप्पणियों का विश्लेषण करके बग, सुरक्षा, प्रदर्शन और शैली पर संरचित प्रतिक्रिया प्रदान करें	repoId (आवश्यक), prNumber (आवश्यक), projectId (वैकल्पिक)
pr-summary	किसी ब्रांच के कमिट इतिहास और डिफ से स्वचालित रूप से PR शीर्षक और विवरण उत्पन्न करें	repoId (आवश्यक), sourceBranch (आवश्यक), targetBranch (वैकल्पिक, डिफ़ॉल्ट: main), projectId (वैकल्पिक)
branch-cleanup	रिपॉजिटरी में ब्रांचों का विश्लेषण करें और हटाने के लिए पुरानी या मर्ज की गई ब्रांचों की अनुशंसा करें	repoId (आवश्यक), projectId (वैकल्पिक)

MCP संसाधन

संसाधन URI	विवरण	MIME प्रकार
pipeline:///{pipelineId}	पाइपलाइन YAML परिभाषा	application/x-yaml
pipeline:///{orgId}/{projectId}/{pipelineId}	पाइपलाइन YAML (स्पष्ट दायरे के साथ)	application/x-yaml
executions:///recent	पिछले 10 पाइपलाइन निष्पादन सारांश	application/json
schema:///pipeline	Harness पाइपलाइन JSON स्कीमा	application/schema+json
schema:///template	Harness टेम्पलेट JSON स्कीमा	application/schema+json
schema:///trigger	Harness ट्रिगर JSON स्कीमा	application/schema+json
schema:///pipeline_v1 (Alpha)	Harness V1 पाइपलाइन JSON स्कीमा (सरलीकृत स्टेज/स्टेप प्रारूप)	application/schema+json
schema:///agent-pipeline	Harness AI एजेंट पाइपलाइन JSON स्कीमा	application/schema+json
agent-docs:///legacy-format	लीगेसी एजेंट स्पेक प्रारूप संदर्भ (agent.step.group.steps / PLUGIN_TASK), create-agent प्रॉम्प्ट द्वारा पढ़ा जाता है जब किसी मौजूदा लीगेसी-प्रारूप एजेंट को अपडेट किया जाता है	text/markdown

टूलसेट फ़िल्टरिंग

डिफ़ॉल्ट रूप से, 45 में से 41 टूलसेट सक्षम हैं। चार टूलसेट ऑप्ट-इन हैं और डिफ़ॉल्ट से बाहर रखे गए हैं:

• ansible — Harness Ansible (इन्वेंट्री, प्लेबुक, होस्ट, गतिविधि)। ऑप्ट-इन क्योंकि यह प्रोजेक्ट-स्कोप्ड है और ऐसी अवधारणाएँ जोड़ता है जिनकी कई उपयोगकर्ताओं को आवश्यकता नहीं होती।
• autonomous_work — डेवलपमेंट Harness (स्वायत्त कार्य)। ऑप्ट-इन; दायरे के लिए टूलसेट विवरण देखें।
• observability-evaluations — अनुसूचित उत्पादन-टेलीमेट्री मूल्यांकन नियम। ऑप्ट-इन क्योंकि यह तैनात स्कोरिंग नियंत्रण प्लेन पर निर्भर करता है।
• registries-v3 — Harness आर्टिफैक्ट रजिस्ट्री v3 (पैकेज, संस्करण, फ़ाइलें, मेटाडेटा, स्कैन, फ़ायरवॉल अपवाद)। ऑप्ट-इन जब तक v3 राइट्स नहीं आते, ताकि एजेंटों को v1 रजिस्ट्री/आर्टिफैक्ट और v3 पैकेज/संस्करणों के बीच अंतर न करना पड़े।

+ उपसर्ग के साथ टूलसेट जोड़ना

सभी डिफ़ॉल्ट के साथ ऑप्ट-इन टूलसेट को स्पष्ट रूप से शामिल करने के लिए + उपसर्ग का उपयोग करें:

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

डिफ़ॉल्ट टूलसेट हटाना

उन टूलसेट को बाहर करने के लिए - उपसर्ग का उपयोग करें जिनकी आपको आवश्यकता नहीं है:

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

+ और - का संयोजन

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

स्पष्ट अनुमत सूची

एक स्पष्ट अल्पविराम-पृथक सूची (बिना उपसर्ग) डिफ़ॉल्ट को पूरी तरह से बदल देती है। केवल सूचीबद्ध टूलसेट सक्षम हैं:

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

उपलब्ध टूलसेट नाम:

टूलसेट	संसाधन प्रकार
platform	organization, project
pipelines	pipeline, pipeline_v1, pipeline_dynamic_execution, execution, execution_inputs, trigger, pipeline_summary, input_set, approval_instance
agents	agent, agent_run
services	service
environments	environment
connectors	connector, connector_catalogue
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 (ऑप्ट-इन)	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. टूल्स सामान्य क्रियाएँ हैं: harness_list, harness_get, आदि। वे एक resource_type पैरामीटर स्वीकार करते हैं जो सही API एंडपॉइंट पर रूट करता है।
2. रजिस्ट्री प्रत्येक resource_type को एक ResourceDefinition से मैप करती है — एक घोषणात्मक डेटा संरचना जो HTTP विधि, URL पथ, पथ/क्वेरी पैरामीटर मैपिंग, और प्रतिक्रिया निष्कर्षण तर्क निर्दिष्ट करती है।
3. डिस्पैच संसाधन परिभाषा को हल करता है, HTTP अनुरोध बनाता है (पथ प्रतिस्थापन, क्वेरी पैराम्स, resource_scope-जागरूक खाता/संगठन/प्रोजेक्ट इंजेक्शन), HarnessClient के माध्यम से Harness API को कॉल करता है, और प्रासंगिक प्रतिक्रिया डेटा निकालता है।
4. टूलसेट फ़िल्टरिंग (HARNESS_TOOLSETS) नियंत्रित करती है कि स्टार्टअप पर रजिस्ट्री में कौन सी संसाधन परिभाषाएँ लोड की जाती हैं।
5. संरचित आउटपुट MCP outputSchema के साथ घोषित किया जाता है; harness_list सख्त क्लाइंट्स के लिए ऐरे और सामान्य सूची रैपर को ऑब्जेक्ट-आकार के structuredContent में बदलता है।
6. डीप लिंक स्वचालित रूप से प्रतिक्रियाओं में जोड़े जाते हैं, प्रत्येक संसाधन के लिए सीधे Harness UI URL प्रदान करते हैं।
7. कॉम्पैक्ट मोड सूची परिणामों से वर्बोज़ मेटाडेटा हटाता है, केवल कार्रवाई योग्य फ़ील्ड (पहचान, स्थिति, प्रकार, टाइमस्टैम्प, डीप लिंक) रखता है ताकि टोकन उपयोग कम से कम हो।

नया संसाधन प्रकार जोड़ना

src/registry/toolsets/ में एक नई फ़ाइल बनाएँ या किसी मौजूदा टूलसेट में एक संसाधन जोड़ें:

// src/registry/toolsets/my-module.ts
import type { ToolsetDefinition } from "../types.js";

export const myModuleToolset: ToolsetDefinition = {
  name: "my-module",
  displayName: "My Module",
  description: "Description of the module",
  resources: [
    {
      resourceType: "my_resource",
      displayName: "My Resource",
      description: "What this resource represents",
      toolset: "my-module",
      scope: "project",                    // "project" | "org" | "account"
      identifierFields: ["resource_id"],
      listFilterFields: ["search_term"],
      operations: {
        list: {
          method: "GET",
          path: "/my-module/api/resources",
          queryParams: { search_term: "search", page: "page", size: "size" },
          responseExtractor: (raw) => raw,
          description: "List resources",
        },
        get: {
          method: "GET",
          path: "/my-module/api/resources/{resourceId}",
          pathParams: { resource_id: "resourceId" },
          responseExtractor: (raw) => raw,
          description: "Get resource details",
        },
      },
    },
  ],
};

फिर इसे src/registry/index.ts में आयात करें और ALL_TOOLSETS ऐरे में जोड़ें। किसी भी टूल फ़ाइल में कोई बदलाव आवश्यक नहीं है।

विकास

# Build
pnpm build

# Watch mode
pnpm dev

# Type check
pnpm typecheck

# Run tests
pnpm test

# Watch tests
pnpm test:watch

# Interactive MCP Inspector
pnpm inspect

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

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

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

प्रोजेक्ट संरचना

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

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

एलिसिटेशन

राइट टूल्स (harness_create, harness_update, harness_delete, harness_execute) उपयोगकर्ता से पुष्टि माँगने के लिए MCP एलिसिटेशन का उपयोग करते हैं जब कार्रवाई के जोखिम के लिए इसकी आवश्यकता होती है — केवल medium_write, high_write, और destructive ऑपरेशन। कम-जोखिम वाले क्रिएट / अपडेट / रीड (जैसे pipeline.create, pipeline.update, hql_query.run) बिना किसी प्रॉम्प्ट के चुपचाप आगे बढ़ते हैं। जब कोई प्रॉम्प्ट दिखाया जाता है, तो उपयोगकर्ता देखता है कि क्या होने वाला है और स्वीकार या अस्वीकार करता है, जिससे उन ऑपरेशनों के लिए वास्तविक मानव-इन-द-लूप अनुमोदन मिलता है जो वास्तव में म्यूटेट या चलाते हैं।

यह कैसे काम करता है:

1. LLM एक राइट टूल को medium_write+ जोखिम के साथ कॉल करता है (जैसे harness_delete, harness_execute pipeline.run)। कम-जोखिम वाले क्रिएट / अपडेट / रीड कोई प्रॉम्प्ट नहीं दिखाते।
2. सर्वर क्लाइंट को ऑपरेशन के सारांश और एक confirm चेकबॉक्स (डिफ़ॉल्ट रूप से चेक किया हुआ) के साथ एक एलिसिटेशन अनुरोध भेजता है।
3. उपयोगकर्ता विवरण देखता है और स्वीकार करें (confirm चेक किए हुए) या अस्वीकार / रद्द करें पर क्लिक करता है।
4. यदि confirm: true के साथ स्वीकार किया जाता है, तो ऑपरेशन आगे बढ़ता है। यदि confirm अनचेक किए हुए स्वीकार किया जाता है, अस्वीकार किया जाता है, या रद्द किया जाता है, तो यह अवरुद्ध हो जाता है और LLM को बताया जाता है (एक स्पष्ट अस्वीकृति आधिकारिक है और टूल कॉल पर confirm: true द्वारा बायपास नहीं की जाती)।

क्लाइंट समर्थन:

क्लाइंट	एलिसिटेशन समर्थन
Cursor	हाँ
VS Code (Copilot)	हाँ
Claude Desktop	अभी नहीं
Devin Desktop	अभी नहीं
MCP Inspector	हाँ

एलिसिटेशन व्यवहार ऑपरेशन जोखिम के अनुसार भिन्न होता है जब क्लाइंट समर्थन अनुपलब्ध हो:

जोखिम स्तर	क्लाइंट एलिसिटेशन का समर्थन करता है	confirm: true पारित	व्यवहार
read, low_write	कोई भी	कोई भी	चुपचाप आगे बढ़ें — कोई प्रॉम्प्ट नहीं दिखाया जाता (confirm का इस जोखिम स्तर पर कोई प्रभाव नहीं है)
medium_write, high_write, destructive	हाँ	कोई भी	उपयोगकर्ता को प्रॉम्प्ट करें। केवल तभी आगे बढ़ें जब उपयोगकर्ता confirm: true (स्कीमा का डिफ़ॉल्ट) के साथ स्वीकार करता है। एक स्पष्ट अस्वीकृति, रद्दीकरण, या 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"} बिना कन्फर्म फ़ील्ड के), लेकिन यह उस क्लाइंट से स्पष्ट अस्वीकृति/रद्दीकरण को ओवरराइड नहीं करता जिसने एलिसिटेशन हैंडशेक पूरा किया।

स्वायत्त मोड

स्वायत्त मोड का अर्थ है कि सर्वर सभी ऑपरेशनों के साथ आगे बढ़ता है — जिसमें राइट और विनाशकारी क्रियाएँ शामिल हैं — बिना पुष्टि के प्रॉम्प्ट किए। इसे सेट करके सक्षम करें:

HARNESS_AUTO_APPROVE_RISK=all

यह डिप्लॉयमेंट-स्तरीय सीमा है: एक बार सेट होने पर, व्यक्तिगत सत्र इससे आगे नहीं बढ़ सकते (हालाँकि वे x-harness-auto-approve-risk हेडर के माध्यम से प्रति-सत्र सख्त थ्रेशोल्ड चुन सकते हैं)।

या अपने MCP क्लाइंट कॉन्फ़िग में:

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

आंशिक स्वायत्तता: आप उच्च-जोखिम वाले ऑपरेशनों के लिए अभी भी प्रॉम्प्ट करते हुए केवल एक विशिष्ट जोखिम स्तर तक स्वतः-अनुमोदन भी कर सकते हैं:

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

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

मान	क्या स्वतः-अनुमोदित है
none (डिफ़ॉल्ट)	कुछ भी नहीं — कोई स्वतः-अनुमोदन थ्रेशोल्ड नहीं
low_write	रीड + कम-जोखिम वाले राइट
medium_write	रीड + कम + मध्यम-जोखिम वाले राइट
high_write	रीड + कम + मध्यम + उच्च-जोखिम वाले राइट
all	सब कुछ, जिसमें विनाशकारी ऑपरेशन शामिल हैं

स्वायत्त मोड चेतावनी: HARNESS_AUTO_APPROVE_RISK=all सभी ऑपरेशनों के लिए पुष्टि छोड़ देता है जिसमें harness_delete शामिल हैं। सावधानी से उपयोग करें और कौन से संसाधन प्रकार उपलब्ध हैं यह प्रतिबंधित करने के लिए HARNESS_TOOLSETS के साथ जोड़ने पर विचार करें।

माइग्रेशन नोट: HARNESS_SKIP_ELICITATION=true अभी भी समर्थित है और HARNESS_AUTO_APPROVE_RISK=all पर मैप करता है। एक डेप्रिकेशन चेतावनी stderr पर लॉग की जाती है। यदि दोनों सेट हैं, तो HARNESS_AUTO_APPROVE_RISK प्राथमिकता लेता है।

सुरक्षा

• सीक्रेट कभी उजागर नहीं होते। secret संसाधन प्रकार केवल मेटाडेटा लौटाता है (नाम, प्रकार, दायरा) — सीक्रेट मान कभी भी किसी प्रतिक्रिया में शामिल नहीं होते।
• पुष्टि-आवश्यक ऑपरेशन उपलब्ध होने पर एलिसिटेशन का उपयोग करते हैं। जब किसी राइट या एक्ज़ीक्यूट क्रिया में medium_write, high_write, या destructive जोखिम होता है, तो harness_create, harness_update, harness_delete, और harness_execute आगे बढ़ने से पहले MCP एलिसिटेशन का प्रयास करते हैं (देखें एलिसिटेशन)। कम-जोखिम वाली क्रियाएँ (read, low_write — जैसे pipeline.create, pipeline.update, hql_query.run) बिना प्रॉम्प्ट के चुपचाप आगे बढ़ती हैं।
• मध्यम-जोखिम और उससे ऊपर विफल-बंद। यदि medium_write, high_write, या destructive ऑपरेशनों के लिए पुष्टि प्राप्त नहीं की जा सकती, तो वे आँख बंद करके निष्पादित होने के बजाय अवरुद्ध हो जाते हैं। स्वायत्त वर्कफ़्लो के लिए HARNESS_AUTO_APPROVE_RISK के साथ ओवरराइड करें।
• CORS समान-मूल तक सीमित। HTTP ट्रांसपोर्ट केवल समान-मूल अनुरोधों की अनुमति देता है, जो localhost पर MCP सर्वर को लक्षित करने वाले दुर्भावनापूर्ण वेबसाइटों से CSRF हमलों को रोकता है।
• HTTP दर सीमा। HTTP ट्रांसपोर्ट अनुरोध बाढ़ को रोकने के लिए प्रति IP प्रति मिनट 60 अनुरोध लागू करता है।
• API दर सीमा। Harness API क्लाइंट अपस्ट्रीम दर सीमाओं से टकराने से बचने के लिए 10 अनुरोध/सेकंड की सीमा लागू करता है।
• पेजिनेशन सीमाएँ लागू। सूची क्वेरीज़ मेमोरी थकावट को रोकने के लिए कुल 10,000 आइटम और प्रति पृष्ठ 100 तक सीमित हैं।
• बैकऑफ़ के साथ पुनः प्रयास। क्षणिक विफलताएँ (HTTP 429, 5xx) एक्सपोनेंशियल बैकऑफ़ और जिटर के साथ पुनः प्रयास की जाती हैं।
• Localhost बाइंडिंग। HTTP ट्रांसपोर्ट डिफ़ॉल्ट रूप से 127.0.0.1 से बाइंड होता है — नेटवर्क से पहुँच योग्य नहीं।
• कोई stdout लॉगिंग नहीं। सभी लॉग stderr पर जाते हैं ताकि stdio JSON-RPC ट्रांसपोर्ट दूषित न हो।

पूरक कौशल

Harness MCP सर्वर Harness Skills के साथ अच्छी तरह से जोड़ा जाता है — सामान्य Harness वर्कफ़्लो के लिए डिज़ाइन किए गए तैयार Claude Code कौशल (स्लैश कमांड) का एक संग्रह। कस्टम प्रॉम्प्ट लिखे बिना /deploy, /rollback, /triage, और अधिक जैसे उच्च-स्तरीय स्वचालन प्राप्त करने के लिए उन्हें इस MCP सर्वर के साथ स्थापित करें।

समस्या निवारण और सामान्य गलतियाँ

लक्षण	संभावित कारण	क्या करें
HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...	API कुंजी समर्थित खाता-स्कोप प्रारूप (pat.<accountId>... या sat.<accountId>...) में नहीं है, इसलिए खाता ID का अनुमान नहीं लगाया जा सकता	HARNESS_ACCOUNT_ID स्पष्ट रूप से सेट करें
Unknown transport: "..." स्टार्टअप पर	असमर्थित CLI ट्रांसपोर्ट तर्क	केवल stdio या http का उपयोग करें
Invalid HARNESS_TOOLSETS: ... स्टार्टअप पर	एक या अधिक टूलसेट नाम पहचाने नहीं गए	केवल टूलसेट फ़िल्टरिंग से नामों का उपयोग करें (सटीक मिलान)
HTTP mcp-session-id header is required...	सत्र अनुरोध सत्र हेडर के बिना भेजा गया	पहले initialize भेजें, फिर POST/GET/DELETE /mcp पर mcp-session-id शामिल करें
HTTP Session not found...	MCP_SESSION_TTL_MS निष्क्रिय मिलीसेकंड के बाद सत्र समाप्त हो गया या पहले ही बंद हो गया	नया सत्र बनाने के लिए initialize फिर से चलाएं, फिर नए हेडर के साथ पुनः प्रयास करें
HTTP 405 Method Not Allowed on /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 create/update/delete/execute को ब्लॉक करता है	यदि लेखन संचालन इच्छित हैं तो HARNESS_READ_ONLY=false सेट करें
पाइपलाइन रन अनसुलझे आवश्यक इनपुट के साथ प्री-फ्लाइट विफल होता है	प्रदान किया गया inputs आवश्यक रनटाइम प्लेसहोल्डर्स को कवर नहीं करता था	runtime_input_template प्राप्त करें, गायब सरल कुंजियाँ प्रदान करें, या संरचनात्मक इनपुट के लिए input_set_ids का उपयोग करें
पाइपलाइन CI शॉर्टहैंड (branch, tag, pr_number, commit_sha) लागू नहीं हुआ	inputs.build पहले से प्रदान किया गया था, इसलिए शॉर्टहैंड विस्तार जानबूझकर छोड़ दिया गया	शॉर्टहैंड विस्तार का उपयोग करने के लिए inputs.build हटाएँ, या पूर्ण स्पष्ट build संरचना रखें
पाइपलाइन रन गलत YAML संशोधन लोड किया	पाइपलाइन परिभाषा Git में संग्रहीत है और रन ने वांछित पाइपलाइन शाखा निर्दिष्ट नहीं की	run क्रिया पर params.pipeline_branch पास करें; यह Harness branch से मैप करता है
wait: true ने _wait.error लौटाया	पाइपलाइन ट्रिगर सफल हुआ, लेकिन सर्वर-साइड पोलिंग विफल रही	पुनः चलाने का निर्णय लेने से पहले harness_get(resource_type="execution", ...) के साथ execution_id पुनः जाँचें
wait: true ने execution_timed_out: true लौटाया	निष्पादन wait_timeout_seconds से पहले टर्मिनल स्थिति तक नहीं पहुँचा	स्थिति पुनः जाँचने के लिए लौटाए गए execution_id का उपयोग करें; harness_diagnose चलाने से पहले टर्मिनल स्थिति की प्रतीक्षा करें
निष्पादन लॉग खाली हैं या ब्लॉब डाउनलोड 403 लौटाते हैं	Harness-होस्टेड लॉग ब्लॉब URL को कॉन्फ़िगर किए गए Harness क्लाइंट/प्रमाणीकरण पथ की आवश्यकता होती है, विशेष रूप से आंतरिक या स्व-प्रबंधित होस्ट के लिए	HARNESS_BASE_URL को लक्षित Harness होस्ट पर इंगित रखें और MCP क्लाइंट को बायपास करने के बजाय harness_get(resource_type="execution_log", ...) या harness_diagnose(..., include_logs=true) का उपयोग करें
Operation declined by user / Operation cancelled by user	उपयोगकर्ता ने अनुरोध पुष्टिकरण संवाद अस्वीकार या रद्द कर दिया — आधिकारिक	उपयोगकर्ता के साथ संचालन विवरण सत्यापित करें; confirm: true स्पष्ट अस्वीकृति को बायपास नहीं करता है। उपयोगकर्ता को संकेत स्वीकार करना होगा
Operation blocked: the client could not surface a usable confirmation prompt	क्लाइंट में अनुरोध समर्थन की कमी है, elicitInput विफल रहा, या अपमानजनक स्वीकृति लौटाई	गैर-इंटरैक्टिव स्वचालन के लिए confirm: true के साथ पुनः प्रयास करें, या अनुरोध समर्थन वाले क्लाइंट का उपयोग करें
टेम्पलेट create/update के लिए body.template_yaml (or body.yaml) is required	टेम्पलेट API पूर्ण YAML पेलोड की अपेक्षा करते हैं	body में पूर्ण template_yaml स्ट्रिंग प्रदान करें; हटाने के लिए, एक संस्करण हटाने के लिए version_label पास करें (सभी संस्करण हटाने के लिए छोड़ें)
स्टार्टअप पर HARNESS_BASE_URL must use HTTPS	HARNESS_BASE_URL HTTP URL पर सेट है	HTTPS का उपयोग करें, या स्थानीय विकास के लिए HARNESS_ALLOW_HTTP=true सेट करें

लाइसेंस

MIT