Harness

Harness MCP Server 2.0

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

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

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

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

• 11 टूल, 274 संसाधन प्रकार। रजिस्ट्री-आधारित dispatch system, harness_list, harness_get, harness_create आदि को किसी भी Harness संसाधन — pipelines, services, environments, orgs, projects, feature flags, cost data और अन्य — तक पहुँचाता है। LLM सैकड़ों के बजाय 11 टूल में से चुनता है।
• पूरे प्लेटफ़ॉर्म का कवरेज। CI/CD, GitOps, Feature Flags, Cloud Cost Management, Security Testing, Chaos Engineering, Database DevOps, Internal Developer Portal, Software Supply Chain, Infrastructure as Code Management, Release Management, Governance, Service Overrides, Knowledge Graph और अन्य क्षेत्रों में फैले 44 डिफ़ॉल्ट toolsets। ज़रूरत पड़ने पर Ansible और observability-evaluation का वैकल्पिक कवरेज उपलब्ध है।
• शुरू से ही कई प्रोजेक्ट वाले workflows। एजेंट संगठनों और प्रोजेक्ट्स को गतिशील रूप से खोजते हैं — hardcoded env vars की ज़रूरत नहीं। "सभी प्रोजेक्ट्स में विफल executions दिखाओ" कहें, तो एजेंट पूरे account hierarchy में नेविगेट कर सकता है।
• 35 prompt templates। आम workflows के लिए पहले से बने prompts: ऐप्स को शुरू से अंत तक build और deploy करना, विफल pipelines को debug करना, DORA metrics की समीक्षा करना, vulnerabilities को triage करना, cloud costs को optimize करना, access control का audit करना, feature flag rollouts की योजना बनाना, pull requests की समीक्षा करना, लंबित pipelines को मंज़ूरी देना और अन्य।
• हर जगह काम करता है। स्थानीय clients (Claude Desktop, Cursor, Devin Desktop) के लिए Stdio transport, दूरस्थ/साझा deployments के लिए HTTP transport, और Docker तथा Kubernetes के लिए तैयार।
• बिना कॉन्फ़िगरेशन के शुरुआत। बस Harness API key दें। Account ID PAT और SAT tokens से अपने-आप निकाला जाता है, org/project defaults वैकल्पिक हैं, और toolset filtering से आप केवल ज़रूरी चीज़ें उपलब्ध करा सकते हैं।
• डिज़ाइन से ही विस्तार योग्य। नया Harness संसाधन जोड़ने के लिए केवल एक declarative data file जोड़नी होती है — नए tool registration, schema changes या prompt updates की ज़रूरत नहीं।

आवश्यकताएँ

सर्वर इंस्टॉल करने या चलाने से पहले, आपको Harness API key चाहिए:

1. अपने Harness account में लॉग इन करें
2. My Profile → API Keys → + New API Key पर जाएँ
3. API key के अंतर्गत नया Token बनाएँ — इससे <prefix>.<accountId>.<tokenId>.<secret> फ़ॉर्मैट में PAT या SAT बनता है
4. Token को किसी सुरक्षित जगह पर सहेजें — अगले चरण में इसकी ज़रूरत होगी

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

तुरंत शुरू करें

विकल्प 0: Hosted Harness MCP

यदि आपके Harness account में hosted MCP service सक्षम है, तो remote MCP servers का समर्थन करने वाले clients सर्वर को स्थानीय रूप से चलाने के बजाय सीधे managed endpoint से कनेक्ट कर सकते हैं।

महत्वपूर्ण: Hosted MCP service, HARNESS_API_KEY के बजाय Harness Platform OAuth का उपयोग करती है। Endpoint का उपयोग करने से पहले इसे हर account के लिए Harness Support द्वारा सक्षम/कॉन्फ़िगर भी किया जाना चाहिए।

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

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

इंस्टॉल करने की ज़रूरत नहीं — बस इसे चलाएँ:

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

या अपने AI client में API key कॉन्फ़िगर करें (नीचे Client Configuration देखें)।

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

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

ध्यान दें: Account ID PAT और SAT tokens (pat.<accountId>... या sat.<accountId>...) से अपने-आप निकाला जाता है, इसलिए HARNESS_ACCOUNT_ID की ज़रूरत केवल उन API keys के लिए है जिनमें account segment शामिल नहीं है।

विकल्प 2: Global Install

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

विकल्प 3: Source से Build करें

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

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

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

Anthropic MCP Directory bundle

MCPB bundle manifest [mcp-directory/](mcp-directory/) में है, और 512×512 bundle icon repository root में [icon.png](icon.png) पर ट्रैक किया जाता है। पैकेज किए गए archive में root-level manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json, और production node_modules/ शामिल हैं।

Archive को छोटा रखने के लिए, MCPB packages को staging directory से build करें:

pnpm prepare:mcpb

Staging directory dist/mcpb/ में लिखी जाती है, जहाँ npm के flat layout का उपयोग करके npm-shrinkwrap.json से production dependencies इंस्टॉल की जाती हैं। Pin किया गया आधिकारिक MCPB CLI इसकी जाँच करता है और dist/harness-mcp-server-<version>.mcpb बनाता है।

v*.*.* से मेल खाने वाले version tags उस bundle को अपने-आप संबंधित GitHub Release पर प्रकाशित करते हैं। npm को दोबारा प्रकाशित किए बिना किसी मौजूदा release को backfill करने के लिए, Release workflow को उसके release_tag input के साथ मैन्युअल रूप से चलाएँ (उदाहरण के लिए, v3.2.20)। Workflow उस सटीक tag को checkout और build करता है, फिर केवल उसका versioned MCPB asset बदलता है।

CLI का उपयोग

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

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

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

HTTP Transport

HTTP mode में चलने पर, सर्वर ये endpoints उपलब्ध कराता है:

Endpoint	Method	विवरण
/mcp	POST	MCP JSON-RPC endpoint (initialize + session requests)
/mcp	GET	सर्वर द्वारा शुरू किए गए संदेशों के लिए SSE stream (progress, elicitation)
/mcp	DELETE	सक्रिय MCP session समाप्त करें
/mcp	OPTIONS	CORS preflight
/health	GET	Health check — { "status": "ok", "sessions": <count> } लौटाता है
/.well-known/oauth-protected-resource	GET	oauth और oauth-proxy modes में RFC 9728 metadata
/.well-known/oauth-protected-resource/mcp	GET	डिफ़ॉल्ट /mcp resource के लिए path-aware RFC 9728 metadata
/.well-known/oauth-authorization-server	GET	oauth-proxy mode में embedded broker RFC 8414 metadata
/oauth/authorize	GET	upstream provider और HarnessID के माध्यम से MCP client login शुरू करें
/oauth/upstream/callback	GET	Upstream identity-provider callback
/oauth/harnessid/callback	GET	HarnessID login callback
/oauth/token	POST	MCP client के लिए upstream tokens लौटाएँ या refresh करें; HarnessID tokens कभी नहीं लौटाता

HTTP transport session-based mode में चलता है। initialize पर नया MCP session बनाया जाता है, सर्वर mcp-session-id header लौटाता है, और उस session के बाद के requests में वही header शामिल होना चाहिए।

HTTP mode में परिचालन संबंधी सीमाएँ:

• साझा या दूरस्थ रूप से पहुँच योग्य single-user और multi-user deployments के लिए HARNESS_MCP_AUTH_TOKEN सेट करें। सेट होने पर, /mcp को भेजे जाने वाले हर POST, GET, और DELETE request में Authorization: Bearer <token> शामिल होना चाहिए।
• OAuth mode, HARNESS_MCP_AUTH_TOKEN के बजाय HarnessID access tokens स्वीकार करता है और unauthenticated opt-out के बिना non-loopback address से bind हो सकता है।
• OAuth proxy mode upstream identity-provider token स्वीकार करता है, उसे आंतरिक रूप से प्रति-user HarnessID token में बदलता है, और हर request पर upstream token की आवश्यकता रखता है।
• डिफ़ॉल्ट रूप से, non-loopback single-user और multi-user binds के लिए HARNESS_MCP_AUTH_TOKEN आवश्यक है। फिर भी non-loopback interface पर बिना authentication के चलाने के लिए, स्पष्ट रूप से HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true सेट करें।
• mcp-session-id के बिना POST /mcp एक initialize request होना चाहिए।
• मौजूदा sessions के लिए POST /mcp, GET /mcp, और DELETE /mcp में mcp-session-id header आवश्यक है।
• SSE notifications (progress updates और elicitation prompts) के लिए GET /mcp का उपयोग किया जाता है।
• जब कोई request या SSE stream सक्रिय न हो, तो idle sessions को MCP_SESSION_TTL_MS milliseconds के बाद हटाया जाता है (डिफ़ॉल्ट 1800000, यानी 30 मिनट)।
• GET /health एकमात्र non-MCP endpoint है।
• Request body का आकार HARNESS_MAX_BODY_SIZE_MB तक सीमित है (डिफ़ॉल्ट 10 MB)।
• उस HTTP session के लिए V0 या V1 pipeline resources चुनने हेतु initialize request पर x-harness-pipeline-version: 0 या 1 सेट करें।
• अधिक सख्त प्रति-session auto-approval threshold चुनने के लिए initialize request पर x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all सेट करें। सर्वर इस मान को deployment-level HARNESS_AUTO_APPROVE_RISK तक सीमित रखता है, इसलिए session कॉन्फ़िगर की गई approval सीमा को घटा सकता है, बढ़ा नहीं सकता।

HarnessID OAuth Mode

Remote MCP clients को HarnessID खोजने और PKCE के साथ OAuth 2.1 Authorization Code पूरा करने देने के लिए HARNESS_MCP_MODE=oauth सेट करें। OAuth mode केवल HTTP transport के साथ उपलब्ध है। Production HarnessID, MCP resource और API routing defaults पहले से शामिल हैं:

HARNESS_MCP_MODE=oauth

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

इस mode में HARNESS_API_KEY सेट नहीं होना चाहिए। HARNESS_MCP_OAUTH_JWKS_URI का डिफ़ॉल्ट <issuer>/protocol/openid-connect/certs है, और account token से मिलने के कारण HARNESS_ACCOUNT_ID की ज़रूरत नहीं है। यदि वैकल्पिक appsec toolset (HARNESS_TOOLSETS=+appsec) सक्षम है, तो sessions को initialize request पर x-harness-appsec-api-key भी देना होगा (HarnessID OAuth tokens कभी भी api.traceable.ai को forward नहीं किए जाते)।

सर्वर RFC 9728 protected-resource metadata प्रकाशित करता है और जब client ने authentication नहीं किया हो, तो यह challenge लौटाता है:

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

यह कॉन्फ़िगर किए गए JWKS endpoint का उपयोग करके HarnessID access token के RS256 signature, iss, expiry और sub की पुष्टि करता है, और azp claim के माध्यम से जाँचता है कि token HARNESS_MCP_OAUTH_CLIENT_ID के लिए जारी किया गया था। HARNESS_MCP_OAUTH_RESOURCE discovery और challenges के लिए उपयोग किया जाने वाला RFC 9728 protected-resource identifier है। मौजूदा HarnessID access tokens MCP URL के बजाय aud: account का उपयोग करते हैं, इसलिए resource की तुलना aud से नहीं की जाती।

Account ID token के HARNESS_MCP_OAUTH_ACCOUNT_CLAIM claim से मिलता है (डिफ़ॉल्ट रूप से account_id), जिसे HarnessID organization scope भरता है। हर session caller का access token संग्रहीत करता है और उसे Harness API में Authorization: Bearer के रूप में forward करता है, ताकि Harness RBAC और audit records साझा PAT के बजाय लॉग इन उपयोगकर्ता को दर्शाएँ। Session उस sub और account से बँधा होता है जिसके साथ इसे बनाया गया था: बाद के request में refreshed token दिया जा सकता है, लेकिन किसी दूसरे उपयोगकर्ता या account का token अस्वीकार कर दिया जाता है।

आमतौर पर clients को केवल MCP resource URL की ज़रूरत होती है:

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

Client protected-resource metadata पढ़ता है, HARNESS_MCP_OAUTH_ISSUER खोजता है, और फिर उस authorization server का RFC 8414 metadata उपयोग करता है। यदि client dynamic client registration का समर्थन नहीं करता, तो पहले से पंजीकृत mcp-client client ID का उपयोग करें।

QA Keycloak checklist और validation commands के लिए स्वयं-होस्ट किए गए MCP server के लिए HarnessID OAuth देखें।

Upstream Identity Provider OAuth Proxy Mode

OAuth proxy mode के लिए confidential HarnessID client चाहिए। Harness ID team यह client बनाती है और client ID तथा client secret देती है। इस mode को सक्षम करने से पहले Harness ID team से संपर्क करें।

जब MCP client को केवल upstream identity-provider token रखना हो, तो HARNESS_MCP_MODE=oauth-proxy सेट करें। Public client name कुछ भी हो सकता है। HARNESS_MCP_BROKER_CLIENT_ID को उसी नाम पर सेट करें जिसका उपयोग MCP client करता है। एकीकृत OAuth broker upstream browser login शुरू करता है, उसी flow में HarnessID login पूरा करता है, और MCP client को केवल upstream access और refresh tokens लौटाता है। हर /mcp request पर, सर्वर upstream token की पुष्टि करता है और प्रति-user HarnessID access token को cache से उपयोग करता है; expiry से पहले उसे refresh token से नवीनीकृत करता है। Upstream से HarnessID तक mapping न मिलने पर 401 लौटता है, ताकि client फिर से sign in करे। HarnessID tokens सर्वर पर ही रहते हैं। Refresh tokens, cached access tokens और अस्थायी OAuth state को rest पर encrypt किया जाता है। यह मोड केवल HTTP के लिए है। इसके लिए upstream issuer और audience, तथा एक स्थिर 32-byte vault key भी आवश्यक है। कॉन्फ़िगरेशन और MCP के end-to-end परीक्षण कमांड के लिए Upstream identity provider OAuth proxy mode देखें।

Multi-User Mode

साझा HTTP deployments के लिए HARNESS_MCP_MODE=multi-user सेट करें, जहाँ हर client अलग Harness user के रूप में authenticate करता है। इस मोड में:

• सर्वर कॉन्फ़िगरेशन में HARNESS_API_KEY सेट नहीं होना चाहिए — सर्वर के पास Harness credentials नहीं होते।
• हर session को initialize अनुरोध पर x-harness-api-key देना होगा। x-harness-account-id केवल तभी आवश्यक है जब API key में account segment शामिल न हो।
• Session के लिए default scope सेट करने हेतु sessions x-harness-org और x-harness-project headers भी दे सकते हैं।
• यदि opt-in appsec toolset (HARNESS_TOOLSETS=+appsec) सक्षम है, तो appsec_* resources को call करने वाले sessions को initialize अनुरोध पर x-harness-appsec-api-key भी देना होगा (session का x-harness-api-key कभी भी api.traceable.ai को forward नहीं किया जाता)।
• उस session के लिए हर Harness API call में Harness API key का उपयोग होता है, इसलिए Harness में audit trail वास्तविक user को दर्शाता है।
• HARNESS_MCP_AUTH_TOKEN स्वतंत्र है और इसे अतिरिक्त transport-layer gate के रूप में अब भी इस्तेमाल किया जा सकता है।

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

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

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

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

HARNESS_MCP_ALLOWED_HOSTS DNS-rebinding सुरक्षा के लिए Host-header validation नियंत्रित करता है, और CORS browser origins को सीमित करता है। इनमें से कोई भी authentication नहीं है; access control के लिए HARNESS_MCP_AUTH_TOKEN या authenticated gateway/reverse proxy का उपयोग करें।

Client Configuration

ध्यान दें: HARNESS_ORG और HARNESS_PROJECT वैकल्पिक हैं। जब tool call में निर्दिष्ट न हों, तो ये उपयोग किए जाने वाले org ID और project ID सेट करते हैं। Agents, harness_list(resource_type="organization") और harness_list(resource_type="project") का उपयोग करके orgs और projects को गतिशील रूप से खोज सकते हैं। पुराने नाम HARNESS_DEFAULT_ORG_ID और HARNESS_DEFAULT_PROJECT_ID अब भी backward compatibility के लिए स्वीकार किए जाते हैं।

Hosted Harness MCP

Harness उन accounts के लिए hosted MCP endpoint भी उपलब्ध कराता है जिनमें managed service सक्षम है। यह तब उपयोगी है जब आप npx harness-mcp-v2 चलाने या HTTP transport को स्वयं host करने के बजाय साझा remote MCP endpoint चाहते हैं।

महत्वपूर्ण: Hosted MCP authentication में Harness Platform OAuth का उपयोग होता है। Client config में HARNESS_API_KEY का उपयोग नहीं होता। Hosted MCP की उपलब्धता हर Harness account के लिए कॉन्फ़िगर की जाती है, इसलिए इसका उपयोग करने से पहले setting सक्षम/कॉन्फ़िगर करवाने के लिए आपको Harness Support से संपर्क करना होगा।

Hosted endpoint https://mcp.harness.io/mcp एक managed service है। Claude, Cursor या Cowork में client-side MCP config यह override नहीं कर सकता कि endpoint किस Harness environment पर route करता है। Harness0 या किसी अन्य private Harness SaaS environment के लिए, Harness Support से उस environment के लिए hosted MCP सक्षम/कॉन्फ़िगर करने को कहें, या local/self-hosted server चलाएँ और HARNESS_BASE_URL को लक्षित Harness host पर सेट करें।

Hosted MCP का उदाहरण:

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

Hosted और local दोनों entries वाला उदाहरण:

{
  "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 की समस्या का निवारण

यह client process-launch की विफलता है, Harness authentication की विफलता नहीं। MCP server अभी शुरू नहीं हुआ है, इसलिए HARNESS_API_KEY बदलने से spawn npx ENOENT पर कोई असर नहीं होगा।

GUI apps (Cursor, Claude Desktop, Devin Desktop, VS Code) को हमेशा आपके shell का PATH नहीं मिलता, इसलिए config reload के बाद वे npx या node ढूँढ़ने में विफल हो सकते हैं। इसे ठीक करने के लिए absolute paths का उपयोग करें और env block में 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"
      }
    }
  }
}

Terminal में which npx और which node से अपने paths खोजें, फिर सुनिश्चित करें कि node वाली directory ऊपर दिए गए PATH value में शामिल हो। आम स्थान:

• Homebrew (macOS): /opt/homebrew/bin/npx
• nvm: ~/.nvm/versions/node/v20.x.x/bin/npx (सटीक path खोजने के लिए nvm which current चलाएँ)
• System Node: /usr/local/bin/npx

Claude Desktop (claude_desktop_config.json)

npx (बिना install किए)

{
  "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 (स्थानीय install)

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

npx (बिना install किए)

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

node (स्थानीय install)

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

फिर अपने environment या .env file में HARNESS_API_KEY सेट करें।

Cursor (.cursor/mcp.json)

npx (बिना install किए, स्थानीय Cursor configs के लिए अनुशंसित)

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

Terminal में which npx चलाएँ और command के लिए उसका पूरा path उपयोग करें; which node वाली directory को PATH के आरंभ में शामिल करें।

node (स्थानीय install)

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 वाली directory को PATH के आरंभ में शामिल करें।

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

npx (बिना install किए)

{
  "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 (स्थानीय install)

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

Source से local build का उपयोग कर रहे हैं?

कमांड को अपने बनाए हुए index.js के path से बदलें:

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

MCP Gateway

Harness MCP server, MCP Gateways के साथ पूरी तरह संगत है — ये ऐसे reverse proxies हैं जो कई MCP servers में केंद्रीकृत authentication, governance, tool routing और observability उपलब्ध कराते हैं। चूँकि server, stdio और HTTP दोनों transports के साथ मानक MCP protocol लागू करता है, इसलिए यह बिना code में बदलाव के किसी भी MCP-compliant gateway के पीछे काम करता है।

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

• केंद्रीकृत credential प्रबंधन — agent configs में API keys की आवश्यकता नहीं
• सभी teams में tool calls के लिए governance और audit logging
• N MCP servers से जुड़ने के बजाय agents के लिए एक endpoint
• Access control — सीमित करें कि कौन-सी teams कौन-से tools इस्तेमाल कर सकती हैं

Docker MCP Gateway

अपने Docker MCP Gateway configuration में server register करें:

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

Portkey

Enterprise governance, cost tracking और multi-LLM routing के लिए Harness MCP server को अपने Portkey MCP Gateway में जोड़ें:

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

LiteLLM

अपने LiteLLM proxy config में जोड़ें:

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

Envoy AI Gateway

Server, HTTP transport के माध्यम से Envoy AI Gateway के MCP support के साथ काम करता है:

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

फिर Envoy को upstream MCP backend के रूप में http://localhost:8080/mcp पर route करने के लिए कॉन्फ़िगर करें।

Kong

अपने मौजूदा Kong gateway infrastructure के माध्यम से Harness MCP server उपलब्ध कराने के लिए Kong के AI MCP Proxy plugin का उपयोग करें।

अन्य Gateways

MCP specification का समर्थन करने वाला कोई भी gateway (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers आदि) इस server को proxy कर सकता है। stdio-आधारित gateways के लिए default transport का उपयोग करें। HTTP-आधारित gateways के लिए server को http transport के साथ शुरू करें और gateway को /mcp endpoint पर point करें।

Docker

Server को Docker container के रूप में build और run करें:

# Build the image
pnpm docker:build

# Run with your .env file
pnpm docker:run

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

Container, built-in health check के साथ, डिफ़ॉल्ट रूप से port 3000 पर HTTP mode में चलता है।

Kubernetes

दिए गए manifests का उपयोग करके Kubernetes cluster पर deploy करें:

# 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

Deployment में readiness/liveness probes, resource limits और non-root security context के साथ 2 replicas चलते हैं। Service, port 80 को आंतरिक रूप से expose करती है (container port 3000 को target करते हुए)।

Configuration

यदि project root में .env file मौजूद हो, तो server उससे environment variables अपने-आप load करता है। .env.example को .env में copy करें और अपनी values भरें। Environment variables को अपने shell या MCP client config के माध्यम से भी सेट किया जा सकता है।

Variable	Required	Default	Description
HARNESS_MCP_MODE	No	single-user	डिप्लॉयमेंट मोड: single-user, multi-user, oauth (सीधा HarnessID टोकन), या oauth-proxy (अपस्ट्रीम पहचान-प्रदाता टोकन, जिसे प्रति-उपयोगकर्ता HarnessID टोकन के लिए एक्सचेंज किया जाता है)
HARNESS_API_KEY	Yes*	--	Harness व्यक्तिगत एक्सेस टोकन या सेवा खाता टोकन। single-user मोड में आवश्यक। multi-user, oauth, या oauth-proxy मोड में सेट नहीं होना चाहिए, जहाँ हर सत्र अपना क्रेडेंशियल लाता है
HARNESS_ACCOUNT_ID	No	(from PAT/SAT)	Harness खाता पहचानकर्ता। एकल-उपयोगकर्ता मोड में PAT/SAT टोकन से स्वतः निकाला जाता है; बहु-उपयोगकर्ता सत्र इसे स्वयं x-harness-account-id के माध्यम से दे सकते हैं, जब API कुंजी में यह शामिल न हो
HARNESS_BASE_URL	No	https://app.harness.io (https://mcp.harness.io/cli in oauth and oauth-proxy)	Harness API/UI बेस URL। oauth और oauth-proxy डिफ़ॉल्ट रूप से होस्ट किए गए MCP /cli प्रॉक्सी के माध्यम से रूट होते हैं; अन्य मोड सीधे Harness SaaS API का उपयोग करते हैं
HARNESS_MCP_OAUTH_ISSUER	No	https://id.harness.io/idp/realms/HarnessIDP	HarnessID जारीकर्ता, जिसका access token के iss क्लेम से सटीक मिलान किया जाता है
HARNESS_MCP_OAUTH_RESOURCE	No	https://mcp.harness.io/mcp	RFC 9728 संसाधन पहचानकर्ता के रूप में प्रकाशित सार्वजनिक कैनोनिकल MCP URL
HARNESS_MCP_OAUTH_JWKS_URI	No	<issuer>/protocol/openid-connect/certs	RS256 access-token हस्ताक्षरों को सत्यापित करने के लिए उपयोग किया जाने वाला HarnessID JWKS एंडपॉइंट
HARNESS_MCP_OAUTH_CLIENT_ID	No	mcp-client	HarnessID क्लाइंट, जिसके लिए access token जारी होना आवश्यक है; टोकन के azp क्लेम से जाँचा जाता है
HARNESS_MCP_OAUTH_ACCOUNT_CLAIM	No	account_id	Harness खाता ID वाला access-token क्लेम, जिसे HarnessID organization स्कोप से भरा जाता है
HARNESS_MCP_OAUTH_SCOPES	No	openid profile email organization	RFC 9728 संरक्षित-संसाधन मेटाडेटा में विज्ञापित, स्पेस से अलग किए गए स्कोप
HARNESS_MCP_OAUTH_CLIENT_SECRET	Yes*	--	Harness ID टीम द्वारा जारी गोपनीय HarnessID क्लाइंट सीक्रेट; केवल oauth-proxy मोड में आवश्यक
HARNESS_MCP_OAUTH_EXTERNAL_SUB_CLAIM	No	external_sub	लिंकिंग के दौरान अपस्ट्रीम सब्जेक्ट या अपस्ट्रीम ईमेल से मिलान किया जाने वाला HarnessID टोकन क्लेम
HARNESS_MCP_OAUTH_PROXY_GRANT	No	refresh	oauth-proxy मोड में बाद के अनुरोधों के लिए ग्रांट: refresh या jwt-bearer
HARNESS_MCP_OAUTH_PROXY_PUBLIC_URL	Yes*	--	OAuth ब्रोकर का सार्वजनिक ओरिजिन। oauth-proxy मोड में आवश्यक और इसका ओरिजिन HARNESS_MCP_OAUTH_RESOURCE के समान होना चाहिए
HARNESS_MCP_OAUTH_PROXY_VAULT_MODE	No	file	file एन्क्रिप्टेड वॉल्ट को एक पॉड के लिए स्थानीय डिस्क पर संग्रहीत करता है। redis पॉड्स के बीच रिफ़्रेश टोकन और लॉगिन स्थिति साझा करता है
HARNESS_MCP_OAUTH_PROXY_VAULT_PATH	No	.harness-mcp/oauth-proxy-vault.enc	एन्क्रिप्टेड HarnessID टोकन और लॉगिन-स्थिति फ़ाइल, जिसका उपयोग तब किया जाता है जब वॉल्ट मोड file हो
HARNESS_MCP_OAUTH_PROXY_VAULT_KEY	Yes*	--	oauth-proxy मोड में आवश्यक Base64-एन्कोडेड 32-बाइट AES कुंजी
HARNESS_MCP_OAUTH_PROXY_REDIS_URL	Yes*	--	redis वॉल्ट मोड में आवश्यक rediss:// URL। redis:// के लिए HARNESS_ALLOW_HTTP=true आवश्यक है। Redis 6.2 या नया
HARNESS_MCP_OAUTH_PROXY_REDIS_KEY_PREFIX	No	harness-mcp:oauth	Redis में OAuth वॉल्ट कुंजियों के लिए प्रीफ़िक्स
HARNESS_MCP_UPSTREAM_ISSUER	Yes*	--	oauth-proxy मोड में आवश्यक सटीक अपस्ट्रीम टोकन जारीकर्ता
HARNESS_MCP_UPSTREAM_AUDIENCE	Yes*	--	oauth-proxy मोड में आवश्यक सटीक अपस्ट्रीम टोकन ऑडियंस
HARNESS_MCP_UPSTREAM_JWKS_URI	No	<upstream issuer>/v1/keys	अपस्ट्रीम RS256 JWKS एंडपॉइंट
HARNESS_MCP_UPSTREAM_SCOPES	No	openid profile email offline_access	एम्बेडेड ब्रोकर द्वारा अनुरोधित और MCP क्लाइंट को प्रकाशित किए गए स्कोप
HARNESS_MCP_UPSTREAM_OAUTH_CLIENT_ID	Yes*	--	एम्बेडेड ब्रोकर द्वारा उपयोग किया जाने वाला गोपनीय अपस्ट्रीम OAuth क्लाइंट
HARNESS_MCP_UPSTREAM_OAUTH_CLIENT_SECRET	Yes*	--	अपस्ट्रीम OAuth क्लाइंट सीक्रेट, जिसका उपयोग केवल सर्वर करता है
HARNESS_MCP_UPSTREAM_DISCOVERY_URI	No	<upstream issuer>/.well-known/openid-configuration	अपस्ट्रीम OIDC डिस्कवरी एंडपॉइंट
HARNESS_MCP_UPSTREAM_EMAIL_DOMAINS	No	--	कॉमा से अलग किए गए डोमेन। ईमेल लिंकिंग के लिए email_verified=true और इस सूची में मौजूद डोमेन आवश्यक है। खाली सूची होने पर ईमेल से लिंक नहीं किया जाता
HARNESS_MCP_BROKER_ISSUER	No	OAuth proxy public URL	वह प्राधिकरण-सर्वर जारीकर्ता, जिसे MCP क्लाइंट खोजता है
HARNESS_MCP_BROKER_CLIENT_ID	No	cursor-harness-mcp	सार्वजनिक OAuth क्लाइंट ID। MCP क्लाइंट को इसी मान के साथ कॉन्फ़िगर करने पर कोई भी नाम काम करता है
HARNESS_MCP_BROKER_REDIRECT_URIS	No	(empty)	कॉमा से अलग किए गए रीडायरेक्ट URI। खाली होने पर हर कॉलबैक अस्वीकार होता है। * केवल लूपबैक http/https की अनुमति देता है। कस्टम स्कीम बिल्कुल उसी रूप में सूचीबद्ध होनी चाहिए
HARNESS_MCP_BROKER_CODE_TTL_MS	No	60000	MCP क्लाइंट को जारी किए गए एक-बार उपयोग वाले प्राधिकरण कोड की अवधि
HARNESS_MCP_BROKER_TRANSACTION_TTL_MS	No	600000	श्रृंखलाबद्ध ब्राउज़र प्राधिकरण लेन-देन की अधिकतम अवधि
HARNESS_FME_API_KEY	No	--	केवल लेगेसी (workspace_id) मोड में fme_ संसाधनों के लिए वैकल्पिक एकल-उपयोगकर्ता/स्व-होस्टेड FME/Split Admin क्रेडेंशियल। OAuth मोड में लेगेसी FME उपलब्ध नहीं है, इसलिए HarnessID टोकन कभी भी api.split.io को नहीं भेजे जाते; इसके बजाय Harness-नेटिव org_id+project_id स्कोप का उपयोग करें। multi-user, oauth, या oauth-proxy मोड में सेट नहीं होना चाहिए
HARNESS_FME_BASE_URL	No	https://api.split.io	केवल लेगेसी (workspace_id) मोड में fme_ संसाधनों द्वारा उपयोग किया जाने वाला Split/FME Admin API बेस URL। स्थानीय विकास के लिए HTTP URL में HARNESS_ALLOW_HTTP=true आवश्यक है। Harness-नेटिव (org_id+project_id) मोड इसे अनदेखा करता है और इसके बजाय मानक HARNESS_API_KEY/HARNESS_BASE_URL का उपयोग करता है
HARNESS_APPSEC_API_KEY	No	--	appsec_ संसाधनों (HARNESS_TOOLSETS=+appsec) के लिए वैकल्पिक एकल-उपयोगकर्ता Traceable Platform API टोकन। HARNESS_API_KEY, सत्र x-harness-api-key, और HarnessID OAuth टोकन कभी भी Traceable को अग्रेषित नहीं किए जाते। multi-user, oauth, या oauth-proxy मोड में सेट नहीं होना चाहिए (होस्ट किए गए सत्र हर सत्र के लिए x-harness-appsec-api-key देते हैं)
HARNESS_APPSEC_BASE_URL	No	https://api.traceable.ai	appsec_ संसाधनों द्वारा उपयोग किया जाने वाला Traceable GraphQL API बेस URL। स्थानीय विकास के लिए HTTP URL में HARNESS_ALLOW_HTTP=true आवश्यक है
HARNESS_APPSEC_UI_URL	No	https://app.traceable.ai	appsec_ संसाधनों पर डीप लिंक के लिए उपयोग किया जाने वाला Traceable वेब UI बेस URL (सेट न होने पर HARNESS_APPSEC_BASE_URL से स्वतः प्राप्त)
HARNESS_ORG	No	--	संगठन ID। इसका उपयोग तब किया जाता है जब प्रति टूल कॉल org_id निर्दिष्ट न हो। यदि इसे छोड़ दिया जाए, तो org_id स्पष्ट रूप से देना आवश्यक है। एजेंट harness_list(resource_type="organization") के माध्यम से संगठन गतिशील रूप से भी खोज सकते हैं
HARNESS_PROJECT	No	--	प्रोजेक्ट ID। इसका उपयोग तब किया जाता है जब प्रति टूल कॉल project_id निर्दिष्ट न हो। एजेंट harness_list(resource_type="project") के माध्यम से प्रोजेक्ट गतिशील रूप से भी खोज सकते हैं
HARNESS_API_TIMEOUT_MS	No	30000	मिलीसेकंड में HTTP अनुरोध टाइमआउट
HARNESS_MAX_RETRIES	No	3	अस्थायी विफलताओं (429, 5xx) के लिए पुनः प्रयासों की संख्या
HARNESS_MAX_BODY_SIZE_MB	No	10	http ट्रांसपोर्ट के लिए HTTP अनुरोध बॉडी का अधिकतम आकार MB में
HARNESS_RATE_LIMIT_RPS	No	10	Harness API के लिए क्लाइंट-साइड अनुरोध सीमा (प्रति सेकंड अनुरोध)
LOG_LEVEL	No	info	लॉग विवरण स्तर: debug, info, warn, error
HARNESS_TOOLSETS	No	(defaults)	कॉमा से अलग की गई टूलसेट सूची। खाली होने पर डिफ़ॉल्ट टूलसेट लोड होते हैं। वैकल्पिक टूलसेट स्पष्ट रूप से शामिल करने के लिए +name और डिफ़ॉल्ट हटाने के लिए -name का समर्थन करता है (देखें टूलसेट फ़िल्टरिंग)
HARNESS_READ_ONLY	No	false	सभी परिवर्तनकारी कार्रवाइयाँ (बनाना, अपडेट करना, हटाना, निष्पादित करना) ब्लॉक करें। केवल सूची और प्राप्त करने की अनुमति है। साझा/डेमो परिवेशों के लिए उपयोगी
HARNESS_SCHEMA_MODE	No	compact	compact (डिफ़ॉल्ट) या full। Compact प्रति-टूल संसाधन-प्रकार enum को साधारण स्ट्रिंग से बदलता है और फ़ील्ड कॉपी को छोटा करता है, जिससे मॉडल को भेजी जाने वाली टूल सूची लगभग आधी हो जाती है (देखें docs/schema-budget.md)। प्रकारों की खोज harness_describe के माध्यम से होती है। हर संसाधन प्रकार को इनलाइन करने के लिए full सेट करें।
HARNESS_AUTO_APPROVE_RISK	No	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	(अल्फ़ा) Pipeline YAML संस्करण। 0 pipeline संसाधन प्रकार लोड करता है और pipeline_v1 को बाहर रखता है; 1 pipeline_v1 लोड करता है और pipeline को बाहर रखता है। HTTP सत्र इसे आरंभ करते समय x-harness-pipeline-version: 0 या 1 से ओवरराइड कर सकते हैं
HARNESS_MCP_ALLOWED_HOSTS	नहीं	--	HTTP ट्रांसपोर्ट के Host-हेडर सत्यापन द्वारा अनुमत, अल्पविराम से अलग किए गए होस्टनाम। लोकलहोस्ट बाइंड के लिए डिफ़ॉल्ट रूप से mcp.harness.io की अनुमति है; प्रॉक्सी/कस्टम डोमेन यहाँ जोड़ें
HARNESS_MCP_AUTH_TOKEN	नहीं	--	सेट होने पर /mcp HTTP रूट पर आवश्यक स्थिर Bearer टोकन। नॉन-लूपबैक सिंगल-यूज़र और मल्टी-यूज़र बाइंड के लिए डिफ़ॉल्ट रूप से आवश्यक। oauth मोड में इसे अनसेट होना चाहिए
HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP	नहीं	false	नॉन-लूपबैक बाइंड पर अनऑथेंटिकेटेड HTTP ट्रांसपोर्ट को स्पष्ट रूप से अनुमति दें। इसका उपयोग केवल किसी अन्य ऑथेंटिकेटेड नियंत्रण के पीछे करें
HARNESS_MCP_TRUST_PROXY	नहीं	0	क्लाइंट IP रिज़ॉल्यूशन के लिए विश्वसनीय रिवर्स प्रॉक्सी / लोड बैलेंसर हॉप की संख्या (Express trust proxy)। सर्वर के सामने मौजूद प्रॉक्सी की संख्या पर सेट करें, ताकि प्रति-IP रेट लिमिटिंग में प्रॉक्सी सॉकेट पीयर के बजाय वास्तविक क्लाइंट का उपयोग हो
HARNESS_MCP_LOG_FILE	नहीं	~/.claude/harness-mcp.log	stdio डिस्कनेक्ट/क्रैश डायग्नोस्टिक्स के लिए उपयोग की जाने वाली फ़ाइल, जब stderr उपलब्ध न हो
HARNESS_LOG_UNSAFE_BODIES	नहीं	false	लॉग में कच्चे अनुरोध/प्रतिक्रिया बॉडी शामिल करें। डिफ़ॉल्ट रूप से बंद, क्योंकि बॉडी में सीक्रेट हो सकते हैं; केवल स्थानीय डीबगिंग के लिए सक्षम करें
HARNESS_AUDIT_FILE	नहीं	--	टिकाऊ स्थानीय संग्रह के लिए ऑडिट इवेंट को newline-delimited 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 (सिमैंटिक सर्च बंद करें और केवल कीवर्ड scatter-gather पर फ़ॉलबैक करें)। एयर-गैप्ड परिवेशों में या स्टार्टअप पर मॉडल लोड करना अवांछित होने पर none का उपयोग करें
HARNESS_SEARCH_SERVICE_URL	नहीं	--	रिमोट सर्च सेवा का बेस URL, जब HARNESS_SEARCH_PROVIDER=remote (उदा. http://search-svc:8080) हो। remote प्रोवाइडर का उपयोग करते समय आवश्यक
HARNESS_SEARCH_SERVICE_HEADERS	नहीं	--	रिमोट सर्च सेवा को हर अनुरोध के साथ भेजे जाने वाले हेडर का JSON ऑब्जेक्ट। किसी भी ऑथ स्कीम का समर्थन करता है: {"Authorization":"Bearer tok"}, {"x-api-key":"key"}, या कई आंतरिक सेवा-से-सेवा हेडर
HARNESS_HF_CACHE_DIR	नहीं	/tmp/hf-cache	local सर्च प्रोवाइडर द्वारा उपयोग किए जाने वाले @huggingface/transformers मॉडल कैश की डायरेक्टरी। रनटाइम डाउनलोड से बचने के लिए Docker इमेज में मॉडल पहले से /app/.cache/hf में शामिल है। प्रोडक्शन डिप्लॉयमेंट में इसे किसी स्थायी वॉल्यूम पथ पर सेट करें
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	नहीं	3	विफल चरणों के लॉग फ़ेच करते समय harness_diagnose द्वारा शुरू किए जाने वाले समवर्ती लॉग-ब्लॉब डाउनलोड की अधिकतम संख्या। इसे केवल तभी बढ़ाएँ जब diagnose की देरी का मुख्य कारण लॉग फ़ेच का वॉल-क्लॉक समय हो और पॉड में पर्याप्त मेमोरी उपलब्ध हो

सिमैंटिक खोज

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

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

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

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

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

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

# 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 कॉन्ट्रैक्ट लागू करता है। यह सरल bag-of-chars एम्बेडिंग का उपयोग करता है, इसलिए मॉडल डाउनलोड करने की आवश्यकता नहीं होती — परिणाम अर्थ की दृष्टि से विश्वसनीय लगते हैं, लेकिन उत्पादन-स्तर के नहीं होते।

HTTPS प्रवर्तन

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

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

ऑडिट लॉगिंग

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

• HARNESS_AUDIT_FILE स्थानीय संग्रह के लिए newline-delimited JSON इवेंट जोड़ता है।
• HARNESS_AUDIT_WEBHOOK_URL { "events": [...] } बैच को HTTPS वेबहुक पर पोस्ट करता है, और वैकल्पिक रूप से HARNESS_AUDIT_WEBHOOK_TOKEN का उपयोग करता है। विफल बैच सीमित क्षमता के साथ फिर से कतार में डाले जाते हैं और अंततः टूल निष्पादन को रोके बिना चेतावनी के साथ छोड़ दिए जाते हैं।
• OTEL_EXPORTER_OTLP_ENDPOINT वैकल्पिक OpenTelemetry peer dependencies इंस्टॉल होने पर ऑडिट स्पैन सक्षम करता है। यदि कोई ट्रेसर प्रदाता पहले से पंजीकृत है, तो सिंक उसका पुनः उपयोग करता है; अन्यथा यह एक स्टैंडअलोन 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, pipeline ID और execution 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 URL भी पाथ में खाता-स्तर या 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 Schema परिभाषाएँ और उदाहरण प्राप्त करें। Pipeline/template स्कीमा बंडल किए गए हैं; connector, environment, service, secret और infrastructure स्कीमा स्कोप-जागरूक entity स्कीमा हैं, जिन्हें बंडल किए गए स्नैपशॉट या NG /yaml-schema से प्राप्त किया जाता है; release_process और release_activity स्कीमा RMG /api/yamlSchema से लाइव प्राप्त किए जाते हैं। path के ज़रिए गहराई से निरीक्षण करने की सुविधा उपलब्ध है।
harness_list	फ़िल्टरिंग, खोज और पृष्ठांकन के साथ दिए गए प्रकार के संसाधनों की सूची बनाएँ।
harness_get	पहचानकर्ता के आधार पर एक संसाधन प्राप्त करें।
harness_create	नया संसाधन बनाएँ। Inline और remote (Git-backed) pipelines समर्थित हैं। elicitation के ज़रिए उपयोगकर्ता की पुष्टि माँगता है।
harness_update	मौजूदा संसाधन अपडेट करें। Inline और remote (Git-backed) pipelines समर्थित हैं। elicitation के ज़रिए उपयोगकर्ता की पुष्टि माँगता है।
harness_delete	संसाधन हटाएँ। elicitation के ज़रिए उपयोगकर्ता की पुष्टि माँगता है। यह विनाशकारी कार्रवाई है।
harness_execute	किसी संसाधन पर कार्रवाई करें (pipeline चलाएँ/पुनः प्रयास करें, Git से pipeline आयात करें, flag टॉगल करें, app सिंक करें)। elicitation के ज़रिए उपयोगकर्ता की पुष्टि माँगता है। Pipeline चलाने के लिए, नीचे दिया गया runtime-input workflow इस्तेमाल करें (branch/tag/pr_number/commit_sha shorthand विस्तार समर्थित है)।
harness_search	एक ही query से Harness संसाधन प्रकारों में खोजें। Semantic routing (स्थानीय all-MiniLM-L6-v2 ONNX embeddings, 384-dim) का उपयोग करके स्टार्टअप पर अनुक्रमित knowledge corpus से प्रासंगिक संसाधन प्रकारों का अनुमान लगाता है — आम तौर पर scatter-gather से पहले ~163 प्रकारों को घटाकर 1–8 तक सीमित करता है। Semantic confidence कम होने पर पूर्ण keyword scatter-gather पर वापस जाता है। Routing सक्रिय होने पर प्रतिक्रिया में semantic_routed और types_skipped शामिल होते हैं। नए संसाधन प्रकारों को खोजने योग्य बनाने के लिए docs/search-guidelines.md देखें।
harness_diagnose	pipeline, connector, delegate, और gitops_application संसाधनों का निदान करें (aliases: execution -> pipeline, gitops_app -> gitops_application)। Pipelines के लिए, stage/step का समय और विफलता का विवरण लौटाता है; connectors/delegates/GitOps apps के लिए, लक्षित स्वास्थ्य और समस्या-निवारण संकेत देता है।
harness_status	रीयल-टाइम project health dashboard प्राप्त करें — हाल के executions, विफलता दरें और deep links।

Schema Lookup Workflow

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

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

उदाहरण:

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

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

Harness entity YAML स्कीमा बदलने पर, मेंटेनर pnpm sync-entity-schemas से vendored entity snapshots को रीफ़्रेश कर सकते हैं।

Tool Examples

उपलब्ध संसाधनों का पता लगाएँ:

{ "resource_type": "pipeline" }

अकाउंट में संगठनों की सूची बनाएँ:

{ "resource_type": "organization" }

किसी संगठन में projects की सूची बनाएँ:

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

किसी project में pipelines की सूची बनाएँ:

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

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

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

Pipeline चलाएँ:

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

Feature flag टॉगल करें:

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

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

{ "query": "payment-service" }

ID के आधार पर execution का निदान करें (summary mode — डिफ़ॉल्ट):

{ "execution_id": "abc123XYZ" }

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

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

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

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

Delegate के स्वास्थ्य का निदान करें:

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

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

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

किसी pipeline की नवीनतम execution report प्राप्त करें:

{ "pipeline_id": "my-pipeline" }

YAML और विफल step logs के साथ पूर्ण diagnostic mode:

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

Logs सक्षम करके summary mode (दोनों का सर्वोत्तम):

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

Project health status प्राप्त करें:

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

Migration type के अनुसार फ़िल्टर किए गए database schemas की सूची बनाएँ:

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

किसी schema के database instances की सूची बनाएँ:

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

किसी schema और instance के लिए resolved LLM authoring pipeline प्राप्त करें:

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

किसी schema instance के snapshot object names (जैसे tables) की सूची बनाएँ:

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

विशिष्ट नामित objects के लिए पूरा snapshot metadata प्राप्त करें:

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

Pipeline Run Workflow (Recommended)

v0 pipelines के लिए, execution के समय input संबंधी त्रुटियाँ कम करने हेतु इस क्रम का उपयोग करें:

1. आवश्यक runtime inputs का पता लगाएँ

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

2. Input रणनीति चुनें

• सरल variables: flat key-value inputs दें (उदाहरण के लिए {"branch":"main","env":"prod"})।

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

• CI codebase shorthand keys (केवल pipeline run के लिए):

  Shorthand key	विस्तारित संरचना
  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 पहले से मौजूद है, तो shorthand विस्तार छोड़ दिया जाता है (स्पष्ट build को प्राथमिकता मिलती है)।

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

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

• ऐसे Git-backed pipelines के लिए जिनका YAML किसी non-default branch से लोड किया जाना चाहिए, params.pipeline_branch दें (Harness को branch के रूप में भेजा जाता है)। यह स्पष्ट definition selector, params.branch alias पर प्राथमिकता रखता है। inputs.branch स्वतंत्र रूप से CI codebase branch चुनता है:

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

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

• आधार संरचना के लिए input_set_ids और सरल overrides के लिए inputs का उपयोग करें।

v1 pipelines के लिए:

1. harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>") प्राप्त करें। Git-backed pipelines के लिए, params के ज़रिए branch_name, connector_ref, और repo_name दें।
2. लौटाए गए प्रत्येक inputs[].details.name को harness_execute.inputs में top-level key के रूप में उपयोग करें।
3. harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}) चलाएँ। Server इन मानों को inputs: YAML root के अंतर्गत रखता है और API का inputs_yaml body भेजता है। यदि आवश्यक फ़ील्ड अनसुलझे हों, तो टूल अपेक्षित कुंजियों और सुझाए गए इनपुट सेटों के साथ प्री-फ़्लाइट त्रुटि लौटाता है। आप harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands) से उपलब्ध संक्षिप्त मैपिंग देख सकते हैं।

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

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

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

सीमाएँ:

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

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

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

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

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

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

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

execution_inputs केवल get के लिए है और इसमें read-risk है। यदि 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 और दोबारा जाँच करने का संकेत शामिल होता है। जब तक आप पुष्टि न कर लें कि पहला निष्पादन चल नहीं रहा है, पाइपलाइन को बिना जाँच के दोबारा न चलाएँ।
• विफल टर्मिनल स्थितियों में harness_diagnose(resource_type="execution", options={execution_id: "..."}) की ओर संकेत करने वाला _diagnose_hint शामिल होता है।

AI DevOps Agent से पाइपलाइन बनाने को कहें:

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

प्राकृतिक भाषा के माध्यम से सेवा अपडेट करें:

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

पाइपलाइन संग्रहण मोड

Harness पाइपलाइनें तीन तरीकों से संग्रहीत की जा सकती हैं:

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

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

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

रिमोट पाइपलाइन बनाएँ (External Git — जैसे GitHub):

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

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

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

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

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

बाहरी Git रिपो से पाइपलाइन इंपोर्ट करें:

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

Harness Code रिपो से पाइपलाइन इंपोर्ट करें:

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

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

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

ट्रिगर हटाएँ:

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

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

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

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

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

इनपुट सेट बनाएँ:

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

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

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

इनपुट सेट हटाएँ:

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

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

44 टूलसेट में व्यवस्थित 274 संसाधन प्रकार। प्रत्येक संसाधन प्रकार CRUD कार्रवाइयों के एक उपसमुच्चय और वैकल्पिक निष्पादन कार्रवाइयों का समर्थन करता है।

प्लेटफ़ॉर्म

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

पाइपलाइनें

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

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

AI एजेंट

संसाधन प्रकार	सूची	प्राप्त करें	बनाएँ	अपडेट करें	हटाएँ	निष्पादन कार्रवाइयाँ
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
llm_model	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 के लिए मौजूदा blob SHA आवश्यक है।

file_content सूची किसी ref पर सभी पथ लौटाती है; get फ़ाइल या डायरेक्टरी की सामग्री लौटाता है (रिपो रूट के लिए path छोड़ें या खाली पास करें; नेस्टेड पथों में स्लैश बनाए रखें)। रिपॉज़िटरी की डिफ़ॉल्ट शाखा उपयोग करने के लिए git_ref छोड़ें — main का अनुमान न लगाएँ।

आर्टिफ़ैक्ट रजिस्ट्री

संसाधन प्रकार	सूची	प्राप्त करें	बनाएँ	अपडेट करें	हटाएँ	कार्रवाइयाँ निष्पादित करें
registry	x	x
artifact	x
artifact_version	x
artifact_file	x

फ़ाइल स्टोर

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

file_store सामान्य टूल के माध्यम से Harness File Store फ़ाइलों और फ़ोल्डरों का प्रबंधन करता है। यह account, org और project scope का समर्थन करता है; resource_scope="account"|"org"|"project" पास करें या Harness File Store URL पेस्ट करें, ताकि सर्वर scope और IDs निर्धारित कर सके।

सामान्य कॉल:

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

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

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

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

टेम्पलेट

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

टेम्पलेट ऑपरेशन Harness Template service paths (/template/api/templates...) का उपयोग करते हैं। Create और update के लिए body.template_yaml या body.yaml में पूरा template YAML string आवश्यक है; version_label update/delete के लिए किसी विशिष्ट version को लक्षित करता है, जबकि version_label के बिना हटाने पर सभी versions हट जाते हैं।

डैशबोर्ड

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

Database DevOps

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

Infrastructure as Code Management (IaCM)

IaCM संसाधन डिफ़ॉल्ट रूप से सक्षम हैं और अधिकतर project-scoped हैं। Workspace identifiers खोजने के लिए iacm_workspace से शुरू करें, फिर workspace संसाधनों, लागतों और activity diffs के लिए उस workspace_id का उपयोग करें। Account, org या project scope पर पुनः उपयोग योग्य variable sets के लिए iacm_variable_set का उपयोग करें। Provider registry account-scoped है।

iacm_module account, org और project scope में काम करता है। यह डिफ़ॉल्ट रूप से account registry का उपयोग करता है; हर ऑपरेशन (list, get, create, update) समान scope_org / scope_project query params भेजता है, इसलिए आपके द्वारा बनाया गया module उसी scope में खोजा जा सकता है जहाँ आपने उसे बनाया था। resource_scope="account" | "org" | "project" और org_id/project_id के माध्यम से scope चुनें। Scope चुनना वैकल्पिक है: जब resource_scope छोड़ा जाता है, तो org_id/project_id केवल तभी लागू होते हैं जब आप उन्हें स्पष्ट रूप से पास करते हैं — कॉन्फ़िगर किए गए HARNESS_ORG/HARNESS_PROJECT defaults लागू नहीं होते, इसलिए कोई ambient project config चुपचाप account module को project के अंतर्गत पंजीकृत नहीं कर सकता। Module body के अपने org/project fields उसके Git connector का स्थान बताते हैं और इस visibility scope से असंबंधित हैं।

iacm_workspace create/update केवल { policy_evaluation } लौटाते हैं — workspace प्राप्त करने के लिए आगे harness_get कॉल करें। iacm_variable_set और iacm_module create/update में स्वयं resource लौटाते हैं। iacm_provider create केवल { id } लौटाता है — आगे harness_get कॉल करें; update केवल version-आधारित है (POST/PUT /providers/{id}/version) — कोई metadata PUT नहीं है। Version writes खाली body लौटा सकते हैं; HarnessClient इसे { status: "SUCCESS", message: "No content" } में सामान्यीकृत करता है।

Variable-set update, full-replacement collections वाला HTTP PUT है — हमेशा पहले harness_get करें, फिर पूरा वांछित body PUT करें (terraform_variables / environment_variables update के लिए आवश्यक हैं; connectors और variable files साफ़ करने के लिए इन्हें छोड़ें/खाली रखें)। Module update भी PUT है — वैकल्पिक fields के लिए पहले get, फिर put करना बेहतर है। Writes medium_write हैं और इनके लिए पुष्टि आवश्यक है (elicitation या confirm: true)।

Variable-set और provider-registry RBAC (iac_variableset_*, iac_providerregistry_*) फिलहाल Harness में Experimental हैं — जब तक iac-server enforcement सक्रिय नहीं करता, access checks हमेशा अनुमति देते हैं। Module registry RBAC (iac_registry_view / iac_registry_edit) Active है और लागू किया जा सकता है। MCP हमेशा caller 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. Workspace खोजने के लिए harness_list(resource_type="iacm_workspace", org_id="...", project_id="...")।
2. नए सिरे से या template (associated_template) से बनाने, अथवा मौजूदा workspace अपडेट करने के लिए iacm_workspace पर harness_create / harness_update — प्रतिक्रिया में केवल { policy_evaluation } मिलता है।
3. बनाए गए/अपडेट किए गए workspace को प्राप्त करने के लिए harness_get(resource_type="iacm_workspace", workspace_id="...")।
4. पुनः उपयोग योग्य Terraform/env variable sets के लिए iacm_variable_set पर harness_list / harness_create / harness_update (वैकल्पिक रूप से resource_scope के साथ) — प्रतिक्रिया VariableSet resource होती है।
5. Module registry के लिए iacm_module पर harness_list / harness_create / harness_update (name + system आवश्यक; org- या project-scoped module के लिए org_id/project_id के साथ resource_scope जोड़ें) — प्रतिक्रिया module resource होती है।
6. Account provider registry के लिए iacm_provider पर harness_list / harness_create / harness_update (create के लिए body.type आवश्यक; create केवल { id } लौटाता है — फिर harness_get कॉल करें; update केवल versions बनाता/अपडेट करता है) — version update खाली success लौटा सकता है।
7. Terraform resources, outputs और data sources देखने के लिए harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...")।
8. प्रति-execution लागत प्रविष्टियों की समीक्षा के लिए harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...")।
9. Plan, apply या destroy activity के लिए संसाधन diffs देखने से पहले और बाद में जाँचने के लिए harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...")।

IaCM list responses में page_count वर्तमान page की गिनती के रूप में दिखता है (सिवाय iacm_variable_set के, जो paginated नहीं है)। जब has_more true हो, तो अगला 1-based page माँगते रहें और कुल संख्या चाहिए होने पर page counts जोड़ें।

Internal Developer Portal (IDP)

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

Pull Requests

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

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

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

Comment thread को resolve करने के लिए harness_execute(resource_type="pr_comment", action="resolve", ...) और उसे फिर से खोलने के लिए action="unresolve" का उपयोग करें; इनमें से किसी में भी body नहीं लिया जाता। comment_id का मान pr_activity की उस row का id होना चाहिए, जहाँ उस row का parent_id null हो; API reply IDs अस्वीकार करता है।

Release Management

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

RMG कॉल ${HARNESS_BASE_URL}/gateway/rmg का उपयोग करते हैं और account scoping Harness-Account header के माध्यम से होती है। Org/project scope में, org_id/project_id दिए जाने पर header-आधारित scoping का उपयोग होता है। release_execution_phase केवल list के लिए है — phase input/output संसाधनों पर harness_get कॉल करते समय प्रत्येक phase item के identifier field को params.phase_identifier के रूप में उपयोग करें (release_execution_phase पर स्वयं harness_get कॉल न करें)। Release list status filtering केवल वर्तमान page पर client-side लागू होती है; यदि परिणाम कई pages में हो सकते हैं, तो समान filters के साथ paging जारी रखें।

संसाधन प्रकार	सूची	प्राप्त करें	बनाएँ	अपडेट करें	हटाएँ	कार्रवाइयाँ निष्पादित करें
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 पर harness_get का उपयोग करें; साथ में release_id और params.phase_identifier / params.activity_identifier / activity_execution_id का उपयोग करें, जैसा कि प्रत्येक संसाधन में बताया गया है।

एकीकृत खोज

वैकल्पिक unified-search टूलसेट (HARNESS_TOOLSETS=+unified-search) उन सभी स्रोतों में अर्थ-आधारित खोज जोड़ता है जिन्हें search-service उपलब्ध कराता है। परिणाम कॉल करने वाले के खाते तक सीमित होते हैं और RBAC फ़िल्टरिंग लागू होती है। खाते में semantic search फ़ीचर फ़्लैग सक्षम होना चाहिए।

संसाधन प्रकार	सूची	प्राप्त करें	कार्रवाइयाँ निष्पादित करें
unified_search	x		search
unified_search_source		x

# 1. Search with the user's words (all sources)
harness_search(query="payments service that keeps crashing")

# 2. Optional: if a hit names a Knowledge Graph type, look it up or query it
harness_get(resource_type="kg_type", resource_id="<type id>", params={kind: "<kind>"})

# 3. Narrow with filters on the hits' metadata keys, per source
harness_execute(resource_type="unified_search", action="search", body={
  query: "payments service that keeps crashing",
  source_filters: {"<source>": {predicate: {field: "<metadata key>", op: "NE", values: [{string_value: "closed"}]}}}
})

harness_get(resource_type="unified_search_source") स्रोतों की सूची देता है। फ़िल्टर सिंटैक्स के लिए harness_describe(resource_type="unified_search") देखें।

यह Semantic Search में मौजूद semantic routing providers से अलग है, जो MCP संसाधन परिभाषाओं और दस्तावेज़ों को इंडेक्स करके harness_search के fan-out को सीमित करते हैं।

Vibe

डिफ़ॉल्ट रूप से सक्षम vibe टूलसेट, ${HARNESS_BASE_URL}/vibe/v1 के अंतर्गत Vibe Orchestrator BFF contract को कवर करता है। यह मौजूदा Harness कनेक्शन और account header का उपयोग करता है; अनुरोध बॉडी में account/org/project query parameters या scope fields नहीं जोड़ता। टीम ने Harness API-key authentication (PAT/SAT) का उपयोग करके Vibe प्रवाह को मान्य किया, इसलिए डिफ़ॉल्ट सत्रों के लिए opt-in सेटिंग आवश्यक नहीं है। चुने गए OpenAPI दस्तावेज़ bearer/session authentication बताते हैं; सर्वर का OAuth मोड मौजूदा सत्र का bearer token आगे भेजता है। स्वचालित regression जाँचें दोनों header paths की पुष्टि करती हैं; gateway authentication अब भी लक्ष्य वातावरण के कॉन्फ़िगरेशन के अधीन है।

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

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

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

डायरेक्टरी पैकेज करते समय, उसे बनाने के लिए आवश्यक स्रोत, manifests, lockfiles, कॉन्फ़िगरेशन और इच्छित uncommitted edits शामिल करें। credentials, .git, इंस्टॉल की गई dependencies और जनरेट किए गए artifacts को बाहर रखें। पैकेजिंग और signed upload वहीं होते हैं जहाँ फ़ाइलें उपलब्ध हों; होस्ट किया गया 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 वैकल्पिक हैं और null हो सकते हैं। OpenAPI द्वारा अनुमत अतिरिक्त prepare फ़ील्ड backend validation के लिए सुरक्षित रखे जाते हैं। तैयारी से projectId, sourceId और upload लौटते हैं, जिनमें प्रत्येक फ़ाइल का uploadUrl, method, headers और expiresAt शामिल होता है। उस signed URL, method और headers का उपयोग करके फ़ाइल bytes सीधे अपलोड करें; URL को बिल्कुल यथावत रखें और storage अनुरोध में Harness credentials न जोड़ें। prepare action स्थानीय फ़ाइलों को पढ़ता या अपलोड नहीं करता।

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

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

JSON imports के लिए, इसके बजाय लौटाया गया id उपयोग करें। Deployment में body: {"project_id": "<Vibe app id>"} या params.app_id भी स्वीकार किए जाते हैं; API wire field snake_case project_id है, जबकि prepare camelCase projectId लौटाता है। सामान्य टूल का शीर्ष-स्तरीय project_id Harness scope identifier है और इसे कभी भी Vibe app id के रूप में उपयोग नहीं किया जाता। Import और prepare ऐप/स्रोत बनाते हैं; इनमें से कोई भी deployment शुरू नहीं करता। लिखने की कार्रवाइयों को स्वचालित रूप से दोबारा प्रयास नहीं किया जाता, और deployment मौजूदा high-risk confirmation policy का उपयोग करता है।

harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>") से प्रगति पढ़ें। यह ऐप URL, execution stages, substeps, failures, log lines और build-analyzer विवरण बनाए रखता है। events execute action resource_id या params.app_id स्वीकार करता है और SSE endpoint को सीमित बैच के रूप में पढ़ता है: अधिकतम 20 JSON events या कनेक्शन के बाद पाँच सेकंड तक, 1 MiB response सीमा के साथ। ये सीमाएँ Vibe endpoint की हैं। कनेक्शन का HARNESS_API_TIMEOUT_MS भी कनेक्शन और stream consumption—दोनों को एक साथ सीमित करता है; समय समाप्त होने पर timeout error लौटता है। पूरा हुआ बैच events और stop_reason (end, event_limit या duration_limit) लौटाता है और stream बंद कर देता है। न तो शुरुआती कनेक्शन विफलताओं और न ही टूटी हुई streams के लिए दोबारा प्रयास किया जाता है। Events अस्थायी diffs हैं और इनके लिए कोई documented replay cursor नहीं है; प्रामाणिक snapshot के लिए lifecycle get का उपयोग करें। दोनों lifecycle reads read-only mode में उपलब्ध हैं।

फ़ीचर फ़्लैग

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

FME (Split.io) संसाधन — fme_* संसाधन dual-mode scoping का समर्थन करते हैं: legacy calls में workspace_id पास करने पर Split.io API (api.split.io) का उपयोग होता है; नए calls में org_id+project_id दोनों पास करने पर इसके बजाय Harness-native endpoints (मानक HARNESS_API_KEY/HARNESS_BASE_URL, अन्य सभी harness_* संसाधनों जैसा ही auth) का उपयोग होता है। एक ही call में workspace_id और org_id/project_id दोनों पास करना, या org_id को अकेले project_id के साथ मिलाना, त्रुटि है — हर call के लिए एक मोड चुनें। नीचे दिए गए प्रत्येक ऑपरेशन legacy mode में उपलब्ध हैं और अपरिवर्तित हैं, जब तक कि संसाधन को केवल Harness-native के रूप में चिह्नित न किया गया हो। Harness-native mode में वर्तमान कवरेज अधिक सीमित है:

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

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

• fme_feature_flag — dual-mode, दोनों branches पूरी तरह wired हैं। Harness-native (org_id+project_id): list/get/create/delete, /fme/api/v4/feature-flags को hit करते हैं (create के लिए body: name, trafficType, वैकल्पिक description/tags/owners, CreateFeatureFlagRequest के अनुसार); update, /fme/api/v4/feature-flags/{name} को merge-patch भेजता है; archive/unarchive, /fme/api/v4/feature-flags/{name}/archive|unarchive को hit करते हैं (केवल वैकल्पिक comment — कोई title नहीं, ArchiveUnarchiveRequest के अनुसार); kill/restore/reallocate, /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate को hit करते हैं और environment_id को query param के रूप में भेजते हैं (वैकल्पिक comment/title, FeatureFlagDefinitionActionRequest के अनुसार)।

• fme_feature_flag_definition — get/create/update dual-mode बने रहते हैं (workspace_id या org_id+project_id)। list/delete/kill/restore/reallocate केवल Harness-native हैं (org_id+project_id) — उन ops के लिए MCP में कभी workspace_id contract नहीं था। Native list के लिए feature_flag_name आवश्यक है और इसमें offset/limit का उपयोग होता है (डिफ़ॉल्ट 100, अधिकतम 100); इसमें environment_id नहीं लिया जाता। Delete और execute के लिए environment_id आवश्यक है। Kill/restore/reallocate, fme_feature_flag वाली कार्रवाइयों के समान हैं। Get/create/update body, legacy से मेल खाता है (treatments, defaultTreatment, defaultRule, वैकल्पिक rules/baselineTreatment/trafficAllocation/comment), साथ ही Harness-native mode में वैकल्पिक title। Native update, JSON Merge Patch है।

• fme_rollout_status — dual-mode list। org_id+project_id (पसंदीदा) या deprecated workspace_id पास करें। Native pagination में offset/limit का उपयोग होता है (अधिकतम 100; harness_list size को limit में मैप किया जाता है); परिणामों को items/total में प्रमोट किया जाता है। हर item में id, name, और वैकल्पिक description होता है।

• fme_rule_based_segment — (Deprecated — fme_segment देखें।) हर operation (list/get/create/delete) पर Harness-native mode अस्वीकार किया जाता है — इसके बजाय fme_segment का उपयोग करें; यह resource केवल legacy workspace_id contract का समर्थन करता है।

• fme_rule_based_segment_definition — (Deprecated — fme_segment_definition देखें।) हर operation/action (list/update/enable/disable/change_request) पर Harness-native mode अस्वीकार किया जाता है — इसके बजाय fme_segment_definition का उपयोग करें (वहाँ कोई enable/disable/change_request समकक्ष नहीं है); यह resource केवल legacy workspace_id/environment_id contract का समर्थन करता है।

• fme_traffic_type — dual-mode list। org_id+project_id (पसंदीदा) या deprecated workspace_id पास करें। Native pagination में offset/limit का उपयोग होता है (अधिकतम 100; harness_list size को limit में मैप किया जाता है); परिणामों को items/total में प्रमोट किया जाता है। हर item में id और name होता है (displayAttributeId नहीं)।

• fme_identity — यदि org_id+project_id एक साथ पास किए जाते हैं, तो create/update अभी लागू नहीं हैं; अन्यथा सामान्य legacy call की तरह आगे बढ़ता है।

• fme_standard_segment — deprecated। Legacy workspace_id अब भी Split v2 को hit करता है। Harness-native अस्वीकार किया जाता है — fme_segment का उपयोग करें।

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

• fme_segment — केवल Native (org_id+project_id)। CRUD। list/get/update/delete के लिए segment_type आवश्यक है: STANDARD | LARGE | RULE_BASED। Create body: name, trafficType, segmentType; वैकल्पिक description, tags, owners।

• fme_segment_definition — केवल Native। CRUD के साथ execute list_keys/add_keys/remove_keys। Update केवल description के लिए है। Keys मौजूद रहने पर Delete, hasDependents के साथ विफल होता है।

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

• fme_event_type — केवल Harness-native (legacy workspace_id समर्थन नहीं)। केवल read-only: list/get, /fme/api/v4/event-types से wired हैं; id event का नाम है। केवल वे event types दिखाई देते हैं जिनमें पिछले 30 दिनों में events हुए हों; यदि कोई event type अनुरोध करने वाले workspace के traffic-type scope से बाहर हो या 30 दिनों से अधिक समय से निष्क्रिय हो, तो get 404 लौटाता है। List filters: name (substring), traffic_type (ID या नाम से), offset/limit (harness_list size को limit में मैप किया जाता है)। किसी ID का अनुमान लगाने के बजाय, fme_metric के baseEventTypes/filterEventType या event_type_ids filter में उसका संदर्भ देने से पहले वास्तविक event type IDs खोजने के लिए इसका उपयोग करें।

• fme_experiment — केवल Harness-native (legacy workspace_id समर्थन नहीं)। CRUD, /fme/api/v4/experiments से wired है। list के लिए parent_type आवश्यक है (FEATURE_FLAG, AI_CONFIG; CONFIG 404 लौटाता है) और जब तक status पास न किया जाए, यह डिफ़ॉल्ट रूप से ACTIVE experiments पर लागू होता है। create के लिए environment_id (query param) और body में parent/name/startAt/endAt/baselineTreatment/comparisonTreatments आवश्यक हैं; parent उस environment में मौजूद होना चाहिए। update, JSON Merge Patch है; parent और environment बदले नहीं जा सकते। delete स्थायी hard delete है — इसे destructive के रूप में वर्गीकृत किया गया है। Create/update पर वैकल्पिक owners: हर entry {type: "USER", id or email} या {type: "GROUP", identifier} होती है। Create/update पर वैकल्पिक rule (वह label जिसके दायरे में targeting-rule परिणाम आते हैं; छोड़ने पर create का डिफ़ॉल्ट "default" होता है, update में null इसे साफ़ करता है) और tags ([{name}]; update सूची को बदल देता है, null/[] इसे साफ़ करता है)। list, tags array filter स्वीकार करता है (ऐसे experiments जिनमें कोई भी tag name हो); items में tags और rule शामिल हैं।

• fme_experiment_settings — किसी एक experiment के सांख्यिकीय और निगरानी संबंधी सेटिंग्स (test type, significance threshold, multiple comparison correction, minimum sample size, review period, variance reduction)। केवल get/update/delete — experiment के साथ 1:1, कोई list नहीं। get हमेशा लागू सेटिंग्स (अपना override या organization defaults) लौटाता है और केवल तभी 404 देता है जब experiment स्वयं मौजूद न हो। update, JSON Merge Patch है और अपने-आप experiment-स्तरीय override बनाता है। delete, organization defaults पर वापस लौटाता है (idempotent) — स्थायी न होने के बावजूद इसे destructive के रूप में वर्गीकृत किया गया है।

• fme_experiment_alerting — क्या कोई एक experiment significance-regression alerting के लिए subscribed है। केवल get/update। जब कोई alert policy मौजूद न हो, तो get, {id, isEnabled} लौटाता है और isEnabled: false रिपोर्ट करता है; यह केवल तभी 404 देता है जब experiment स्वयं मौजूद न हो। update, आवश्यक isEnabled boolean वाला JSON Merge Patch है।

• fme_experiment_result — किसी experiment के नवीनतम calculation run के प्रति-metric मूल्यांकित परिणाम। केवल list (कोई get नहीं — परिणामों का अपना कोई identifier नहीं होता)। सभी metric categories में हर (metric, comparison treatment) जोड़ी के लिए एक row। वैकल्पिक filters: metric_ids, comparisons। केवल नवीनतम run को दर्शाता है — ऐतिहासिक डेटा उपलब्ध नहीं।

Single-user/self-hosted mode में, legacy-mode auth, HARNESS_FME_API_KEY से Bearer token का उपयोग करता है और उसके न होने पर non-placeholder HARNESS_API_KEY का उपयोग करता है। HARNESS_FME_API_KEY legacy Split admin key या FME-entitled Harness PAT/SAT हो सकता है, लेकिन multi-user mode में इसे अस्वीकार किया जाता है, ताकि shared deployments हर session user के credential को override न कर सकें। Harness platform APIs के लिए hosted OAuth/service-routing credentials, सीधे Split.io requests को authenticate नहीं करते। fme_feature_flag, legacy mode में पूर्ण lifecycle management का समर्थन करता है: create (इसके लिए traffic_type_id आवश्यक है), list, get, metadata update, delete, और kill/restore/reallocate/archive/unarchive execute actions। Traffic type IDs खोजने के लिए fme_traffic_type, identity attributes बनाने/अपडेट करने के लिए fme_identity, और standard segments देखने तथा member keys जोड़ने के लिए fme_standard_segment / fme_segment_keys का उपयोग करें। fme_rule_based_segment, targeting segments के लिए CRUD प्रदान करता है, जबकि fme_rule_based_segment_definition, enable/disable और change request approval flows के साथ environment-specific segment rules प्रबंधित करता है।

GitOps

संसाधन प्रकार	सूची	प्राप्त करें	बनाएँ	अपडेट करें	हटाएँ	कार्रवाइयाँ निष्पादित करें
gitops_agent	x	x
gitops_agent_metrics	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	x	run, stop, list_metadata, update_cron
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	x	x	create_from_template, list_revisions, get_variables, get_yaml, compare_revisions
chaos_probe	x	x	x		x	list_metadata, enable, verify, get_manifest
chaos_probe_in_run	x
chaos_probe_template	x	x	x	x	x	get_variables
chaos_infrastructure	x	x	x	x	x
chaos_k8s_infrastructure	x	x	x	x	x	check_health, get_yaml, get_manifest, helm_command
chaos_enabled_infrastructure	x
chaos_environment	x
chaos_hub	x	x	x	x	x	list_metadata
chaos_hub_fault	x
chaos_fault	x	x			x	list_metadata, get_variables, get_yaml
chaos_fault_template	x	x	x	x	x	list_revisions, get_variables, get_yaml, compare_revisions
chaos_fault_experiment_run	x
chaos_action	x	x	x	x	x	list_metadata, get_manifest
chaos_action_template	x	x	x	x	x	list_revisions, get_variables, compare_revisions
chaos_loadtest	x	x	x	x	x	run, stop, estimate_workers, convert_har
chaos_loadtest_run	x	x				status, live_metrics, ai_insights, generate_ai_insights
chaos_service	x	x	x	x	x	list_experiment_runs, list_load_tests
custom_service	x	x	x	x
chaos_application_map	x	x			x
discovered_agent	x
discovered_namespace	x
discovered_service	x
discovered_network_map	x
chaos_guard_condition	x	x	x	x	x
chaos_guard_rule	x	x	x	x	x	enable
chaos_recommendation	x	x
chaos_onboarding	x	x	x		x	stats, confirm_discovery, onboard_services, confirm_service_onboarding, trigger_risk_scan, risk_scan, confirm_risk_scan, list_services, confirm_network_map, confirm_experiment_creation, confirm_experiment_run, skip, stop
chaos_pipeline_onboarding	x	x	x		x	can_onboard
chaos_risk	x	x
chaos_dr_test	x		x
scanned_risk	x	x				occurrences, summary_by_service
chaos_risk_rule	x	x	x	x	x
chaos_risk_scan	x	x	x	x	x	retry, abort, report, report_download, heatmap, submit_findings
chaos_dashboard	x	x		x
chaos_image_registry		x	x	x		resolve

क्लाउड लागत प्रबंधन (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, get के लिए drilldown
sei_ai_usage	x	x				aspect पास करें: metrics, breakdown, summary, top_languages
sei_ai_adoption	x	x				aspect पास करें: metrics, breakdown, summary
sei_ai_impact		x				aspect पास करें: pr_velocity, rework
sei_ai_raw_metric	x

सॉफ़्टवेयर आपूर्ति शृंखला आश्वासन (SCS)

संसाधन प्रकार	सूची	प्राप्त करें	बनाएँ	अपडेट करें	हटाएँ	कार्रवाइयाँ निष्पादित करें
scs_artifact_source	x
artifact_security	x	x
scs_artifact_component	x
scs_artifact_remediation		x
scs_chain_of_custody		x
scs_compliance_result	x
code_repo_security	x	x
scs_sbom		x

Evidence Vault

Evidence Vault in-toto attestations (SDLC evidences) संग्रहीत करता है। सूची में resource_scope के माध्यम से account/org/project scope समर्थित है। एकल free-text फ़िल्टर (pipeline, केवल artifact, gitoid) के लिए search_term का उपयोग करें; अतिरिक्त Name constraint के लिए filters.subject_name का उपयोग करें; subject content digest के लिए filters.subject_digest का उपयोग करें। Get, gitoid_sha256 के आधार पर खोजता है और इसके लिए org_id/project_id (सूची की पंक्ति से) आवश्यक हैं। Download (harness_execute action download) समय-सीमित download_url लौटाता है — यह लिंक हमेशा उपयोगकर्ता को दिखाएँ। इसके लिए feature flag 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 create एक high_write operation है। सर्वर प्रमाणित PAT से requester_id प्राप्त करता है, exemptFutureOccurrences=true सेट करता है, और यदि प्रदान न किया गया हो तो duration_days को डिफ़ॉल्ट रूप से 30 पर सेट करता है। Exemptions की सूची बनाने के लिए, छोटा स्पष्ट page size (उदाहरण के लिए filters: { "status": "Pending", "size": 5 }) पास करें और प्रत्येक response में लौटाए गए _nextPageHint का अनुसरण करें।

सुरक्षा exemption निष्पादन कार्यप्रवाह:

• harness_list का उपयोग resource_type="security_exemption" और स्पष्ट status के साथ करें, जैसे Pending, Approved, Rejected, Expired, या Canceled।
• harness_execute का उपयोग action="approve" और आवश्यक body.scope के साथ करें: CURRENT, ACCOUNT, ORG, या PROJECT। CURRENT exemption के मौजूदा scope पर अनुमोदन करता है; अन्य scopes आंतरिक रूप से STO promote endpoint का उपयोग करते हैं। यदि body.approver_id छोड़ा गया हो, तो सर्वर इसे प्रमाणित उपयोगकर्ता से स्वतः भरता है; body.comment वैकल्पिक है।
• किसी exemption को अस्वीकार करने के लिए action="reject" का उपयोग करें। यदि body.approver_id छोड़ा गया हो, तो यह भी स्वतः भर दिया जाता है।
• कोई अलग promote execute action नहीं है। जब अनुरोधित परिणाम account, organization, या project scope पर अनुमोदन हो, तो गैर-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	विवरण	पैरामीटर
build-deploy-app	शुरू से अंत तक CI/CD वर्कफ़्लो: git repo को स्कैन करें, CI pipeline जनरेट करें (Docker image बनाएँ और push करें), K8s manifests खोजें या जनरेट करें, CD pipeline बनाएँ और deploy करें — CI विफलताओं पर स्वतः पुनः प्रयास (अधिकतम 5 प्रयास) और CD विफलताओं पर (उपयोगकर्ता की अनुमति से अधिकतम 3 प्रयास)। सभी पुनः प्रयास समाप्त होने पर, मैन्युअल जाँच के लिए बनाए गए सभी संसाधनों के Harness UI के डीप लिंक प्रदान करता है।	repoUrl (आवश्यक), imageName (आवश्यक), projectId (वैकल्पिक), namespace (वैकल्पिक)
debug-pipeline-failure	विफल execution का विश्लेषण करें: execution ID, pipeline ID या Harness URL स्वीकार करता है। harness_diagnose के ज़रिए stage/step का विवरण, विफलता की जानकारी, delegate की जानकारी और विफल step के लॉग प्राप्त करता है, फिर मूल कारण का विश्लेषण और सुझाए गए समाधान देता है। क्रमबद्ध pipeline विफलताओं का स्वतः अनुसरण करता है।	executionId (वैकल्पिक), projectId (वैकल्पिक)
pipeline_summarizer	pipeline execution के सभी step लॉग प्राप्त करें और उनका सारांश दें। हर step का लॉग पाने के लिए harness_diagnose को include_logs: true, include_all_step_logs: true के साथ उपयोग करता है, फिर Step Name, Status, Duration और What Happened (लॉग-आधारित सारांश) वाले कॉलम की तालिका प्रस्तुत करता है। कोई भी step छोड़ा नहीं जाता।	executionId (वैकल्पिक), projectId (वैकल्पिक)
create-pipeline	प्राकृतिक भाषा में दी गई आवश्यकताओं से नया pipeline YAML जनरेट करें और संदर्भ के लिए मौजूदा संसाधनों की समीक्षा करें	description (आवश्यक), projectId (वैकल्पिक)
create-agent	Harness AI agent को इंटरैक्टिव तरीके से बनाएँ — मौजूदा agents की जाँच करें (अपडेट करते समय वर्तमान agent.uses बनाम पुराने agent.step.group.steps spec फ़ॉर्मैट का पता लगाएँ), आवश्यकताएँ जुटाएँ, उपयुक्त फ़ॉर्मैट में agent spec जनरेट करें, उपयोगकर्ता से पुष्टि करें, फिर harness_create/harness_update के ज़रिए बनाएँ या अपडेट करें	agent_name (आवश्यक), task_description (आवश्यक), org_id (वैकल्पिक), project_id (वैकल्पिक)
onboard-service	नए service को environments और deployment pipeline के साथ onboard करने की प्रक्रिया में मार्गदर्शन करें	serviceName (आवश्यक), projectId (वैकल्पिक)
dora-metrics-review	DORA metrics (deployment frequency, change failure rate, MTTR, lead time) की समीक्षा करें, Elite/High/Medium/Low वर्गीकरण और सुधार के सुझावों के साथ	teamRefId (वैकल्पिक), dateStart (वैकल्पिक), dateEnd (वैकल्पिक)
setup-gitops-application	GitOps application को onboard करने में मार्गदर्शन करें — agent, cluster और repo की पुष्टि करें तथा application बनाएँ	agentId (आवश्यक), projectId (वैकल्पिक)
chaos-resilience-test	fault injection, probes और अपेक्षित परिणामों के साथ service की resilience जाँचने के लिए chaos experiment डिज़ाइन करें	serviceName (आवश्यक), projectId (वैकल्पिक)
feature-flag-rollout	सुरक्षा गेट के साथ environments में progressive feature flag rollout की योजना बनाएँ और उसे निष्पादित करें	flagIdentifier (आवश्यक), projectId (वैकल्पिक)
migrate-pipeline-to-template	मौजूदा pipeline का विश्लेषण करें और उससे दोबारा उपयोग किए जा सकने वाले stage/step templates निकालें	pipelineId (आवश्यक), projectId (वैकल्पिक)
delegate-health-check	delegate की connectivity, health और token status जाँचें तथा infrastructure समस्याओं का निवारण करें	projectId (वैकल्पिक)
developer-portal-scorecard	services के लिए IDP scorecards की समीक्षा करें और developer experience बेहतर करने के लिए कमियाँ पहचानें	projectId (वैकल्पिक)
pending-approvals	approval की प्रतीक्षा कर रहे pipeline executions खोजें, विवरण दिखाएँ और approve या reject करने का विकल्प दें	projectId (वैकल्पिक), orgId (वैकल्पिक), pipelineId (वैकल्पिक)

FinOps

Prompt	विवरण	पैरामीटर
optimize-costs	cloud cost डेटा का विश्लेषण करें, संभावित बचत के आधार पर प्राथमिकता देते हुए सुझाव और असामान्यताएँ सामने लाएँ	projectId (वैकल्पिक)
cloud-cost-breakdown	trend analysis और anomaly detection के साथ service, environment या cluster के अनुसार cloud costs का गहन विश्लेषण करें	perspectiveId (वैकल्पिक), projectId (वैकल्पिक)
commitment-utilization-review	reserved instance और savings plan के उपयोग का विश्लेषण करके बर्बादी पहचानें और प्रतिबद्धताओं को अनुकूलित करें	projectId (वैकल्पिक)
cost-anomaly-investigation	cost anomalies की जाँच करें — मूल कारण, प्रभावित संसाधन और सुधार के उपाय निर्धारित करें	projectId (वैकल्पिक)
rightsizing-recommendations	rightsizing सुझावों की समीक्षा करें और उन्हें प्राथमिकता दें; वैकल्पिक रूप से Jira या ServiceNow tickets बनाएँ	projectId (वैकल्पिक), minSavings (वैकल्पिक)

DevSecOps

Prompt	विवरण	पैरामीटर
security-review	Harness संसाधनों में सुरक्षा समस्याओं की समीक्षा करें और गंभीरता के अनुसार सुधार के सुझाव दें	projectId (वैकल्पिक), severity (वैकल्पिक, डिफ़ॉल्ट: critical,high)
vulnerability-triage	pipelines और artifacts में सुरक्षा कमजोरियों का triage करें और गंभीरता तथा exploitability के आधार पर प्राथमिकता दें	projectId (वैकल्पिक), severity (वैकल्पिक)
sbom-compliance-check	artifacts के SBOM और compliance स्थिति का ऑडिट करें — license जोखिम, policy उल्लंघन और component की कमजोरियाँ	artifactId (वैकल्पिक), projectId (वैकल्पिक)
supply-chain-audit	सॉफ़्टवेयर supply chain सुरक्षा का शुरू से अंत तक ऑडिट — provenance, chain of custody और policy compliance	projectId (वैकल्पिक)
security-exemption-review	लंबित सुरक्षा छूटों की समीक्षा करें और सामूहिक स्वीकृति या अस्वीकृति के निर्णय लें	projectId (वैकल्पिक)
bulk-exemption-create	स्पष्ट दायरे और अवधि संबंधी मार्गदर्शन के साथ कई STO समस्याओं के लिए उचित सुरक्षा छूट बनाएँ	projectId (आवश्यक), exemption_type (आवश्यक), reason (आवश्यक), issue filters (वैकल्पिक)
access-control-audit	न्यूनतम विशेषाधिकार लागू करने के लिए उपयोगकर्ता अनुमतियों, आवश्यकता से अधिक विशेषाधिकार वाले खातों और role assignments का ऑडिट करें	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 Schema	application/schema+json
schema:///template	Harness टेम्पलेट JSON Schema	application/schema+json
schema:///trigger	Harness ट्रिगर JSON Schema	application/schema+json
schema:///pipeline_v1 (अल्फ़ा)	Harness V1 पाइपलाइन JSON Schema (सरलीकृत stages/steps फ़ॉर्मैट)	application/schema+json
schema:///agent-pipeline	Harness AI एजेंट पाइपलाइन JSON Schema	application/schema+json
agent-docs:///legacy-format	लेगेसी एजेंट स्पेक फ़ॉर्मैट संदर्भ (agent.step.group.steps / PLUGIN_TASK), मौजूदा लेगेसी-फ़ॉर्मैट एजेंट को अपडेट करते समय create-agent प्रॉम्प्ट इसे पढ़ता है	text/markdown

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

डिफ़ॉल्ट रूप से, 50 में से 44 टूलसेट सक्षम हैं। पाँच टूलसेट वैकल्पिक हैं और डिफ़ॉल्ट में शामिल नहीं हैं:

• ansible — Harness Ansible (इन्वेंटरी, प्लेबुक, होस्ट, गतिविधि)। यह प्रोजेक्ट-स्कोप वाला है और इसमें ऐसी अवधारणाएँ शामिल हैं जिनकी कई उपयोगकर्ताओं को ज़रूरत नहीं होती, इसलिए इसे वैकल्पिक रखा गया है।
• appsec — Traceable Application & API Security (API इन्वेंटरी, OpenAPI स्पेक, नमूना स्पैन, संवेदनशील डेटा प्रकार, रनटाइम थ्रेट गतिविधियाँ, सुरक्षा इवेंट, AST स्कैन और इन्वेंटरी ट्रेंड)। इसके लिए एक समर्पित HARNESS_APPSEC_API_KEY की आवश्यकता होती है और यह api.traceable.ai को लक्षित करता है, इसलिए इसे वैकल्पिक रखा गया है।
• autonomous_work — Development Harness (स्वायत्त कार्य)। वैकल्पिक; स्कोप के लिए टूलसेट विवरण देखें।
• observability-evaluations — शेड्यूल किए गए प्रोडक्शन-टेलीमेट्री मूल्यांकन नियम। यह डिप्लॉय किए गए स्कोरिंग कंट्रोल प्लेन पर निर्भर करता है, इसलिए इसे वैकल्पिक रखा गया है।
• unified-search — source search-service द्वारा उपलब्ध कराए गए सभी स्रोतों में सिमेंटिक खोज। बैकएंड हर क्लस्टर पर डिप्लॉय नहीं होता और इसे प्रति खाते फ़ीचर-फ़्लैग से नियंत्रित किया जाता है, इसलिए इसे वैकल्पिक रखा गया है (Unified Search देखें)।
• registries-v3 — Harness Artifact Registry 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, llm_model
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, fme_experiment, fme_experiment_settings, fme_experiment_alerting, fme_experiment_result
gitops	gitops_agent, gitops_agent_metrics, 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_loadtest_run, chaos_service, custom_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_onboarding, chaos_pipeline_onboarding, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan, chaos_dashboard, chaos_image_registry
ccm	cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment
sei	sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric
scs	scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom
evidence-vault	attestation
sto	security_issue, security_issue_filter, security_exemption, remediation_diff
dbops	database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline
autonomous_work (opt-in)	work_item, work_item_resume, work_item_approve, work_timeline, work_budget, work_phase, work_phase_artifact, work_artifact, budget, budget_grant, budget_usage, work_class, work_trigger, capability, risk_evaluator, team, member, member_template, software_component, content_source_connector
access_control	user, user_group, service_account, role, role_assignment, resource_group, permission
governance	policy, policy_set, policy_evaluation
freeze	freeze_window, global_freeze
overrides	service_override
settings	सेटिंग
knowledge-graph	kg_queryable_type_summary, kg_grammar, hql_query
semantic-layer	kg_type, kg_related_type
unified-search (opt-in)	unified_search, unified_search_source
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_git_registration, eval_prompt, online_eval
observability-evaluations (opt-in)	observability_eval
iacm	iacm_workspace, iacm_variable_set, iacm_resource, iacm_module, iacm_provider, iacm_workspace_costs, iacm_activity_resource_change
ansible (opt-in)	ansible_inventory, ansible_playbook, ansible_host, ansible_host_activity, ansible_activity
registries-v3 (opt-in)	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
timelines	activity_timeline
appsec (opt-in)	appsec_api, appsec_api_spec, appsec_api_span, appsec_entity, appsec_vulnerability, appsec_threat_activity, appsec_security_event, appsec_ast_scan, appsec_inventory_trend, appsec_datatype

आर्किटेक्चर

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

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

1. टूल सामान्य क्रियाएँ हैं: harness_list, harness_get, आदि। ये एक resource_type पैरामीटर स्वीकार करते हैं, जो सही API endpoint पर रूट करता है।
2. रजिस्ट्री हर resource_type को एक ResourceDefinition से मैप करती है — एक घोषणात्मक डेटा संरचना, जो HTTP method, URL path, path/query पैरामीटर मैपिंग और response extraction लॉजिक निर्दिष्ट करती है।
3. डिस्पैच resource definition को हल करता है, HTTP request बनाता है (path substitution, query params, resource_scope-aware account/org/project injection), HarnessClient के ज़रिए Harness API को कॉल करता है और संबंधित response data निकालता है।
4. टूलसेट फ़िल्टरिंग (HARNESS_TOOLSETS) नियंत्रित करती है कि स्टार्टअप पर कौन-सी resource definitions रजिस्ट्री में लोड हों।
5. संरचित आउटपुट MCP outputSchema के साथ घोषित किया जाता है; harness_list arrays और सामान्य list wrappers को strict clients के लिए object-आकार वाले structuredContent में बदलता है।
6. डीप लिंक responses में अपने-आप जोड़े जाते हैं, जिससे हर resource के लिए सीधे Harness UI URLs मिलते हैं।
7. कॉम्पैक्ट मोड list results से विस्तृत metadata हटाता है और केवल काम के fields (identity, status, type, timestamps, deep links) रखता है, ताकि token का उपयोग कम से कम हो।

नया Resource Type जोड़ना

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

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

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

फिर इसे src/registry/index.ts में import करें और ALL_TOOLSETS array में जोड़ें। किसी भी tool फ़ाइल में बदलाव की ज़रूरत नहीं है।

विकास

# 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 elicitation का उपयोग करके तब उपयोगकर्ता से पुष्टि माँगते हैं, जब कार्रवाई के जोखिम के कारण इसकी ज़रूरत हो — केवल medium_write, high_write, और destructive ऑपरेशनों के लिए। कम जोखिम वाले create / update / read ऑपरेशन (जैसे pipeline.create, pipeline.update, hql_query.run) बिना किसी prompt के आगे बढ़ते हैं। Prompt दिखने पर उपयोगकर्ता देखता है कि क्या होने वाला है और स्वीकार या अस्वीकार करता है, जिससे वास्तव में बदलाव करने या चीज़ें चलाने वाले ऑपरेशनों के लिए मानव-इन-द-लूप अनुमोदन मिलता है।

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

1. LLM, medium_write+ जोखिम वाला write tool कॉल करता है (जैसे harness_delete, harness_execute pipeline.run)। कम जोखिम वाले create / update / read ऑपरेशनों के लिए prompt नहीं दिखता।
2. सर्वर, ऑपरेशन के सारांश और confirm checkbox (डिफ़ॉल्ट रूप से चयनित) के साथ client को elicitation request भेजता है।
3. उपयोगकर्ता विवरण देखता है और Accept (confirm चयनित होने पर) या Decline / Cancel पर क्लिक करता है।
4. यदि confirm: true के साथ स्वीकार किया जाता है, तो ऑपरेशन आगे बढ़ता है। यदि confirm अचयनित होने पर स्वीकार किया जाता है, अस्वीकार किया जाता है या रद्द किया जाता है, तो इसे रोक दिया जाता है और LLM को इसकी सूचना दी जाती है (स्पष्ट अस्वीकृति अंतिम होती है और tool call पर मौजूद confirm: true इसे दरकिनार नहीं करता)।

Client समर्थन:

Client	Elicitation समर्थन
Cursor	हाँ
VS Code (Copilot)	हाँ
Claude Desktop	अभी नहीं
Devin Desktop	अभी नहीं
MCP Inspector	हाँ

Client समर्थन उपलब्ध न होने पर elicitation का व्यवहार ऑपरेशन के जोखिम के अनुसार बदलता है:

जोखिम स्तर	Client elicitation का समर्थन करता है	confirm: true पास किया गया	व्यवहार
read, low_write	कोई भी	कोई भी	बिना prompt के आगे बढ़ें — कोई prompt नहीं दिखता (confirm का इस जोखिम स्तर पर कोई प्रभाव नहीं है)
medium_write, high_write, destructive	हाँ	कोई भी	उपयोगकर्ता से prompt करें। केवल तभी आगे बढ़ें जब उपयोगकर्ता confirm: true के साथ स्वीकार करे (schema का डिफ़ॉल्ट)। स्पष्ट अस्वीकृति, रद्द करना या confirm: false के साथ स्वीकार करना (उपयोगकर्ता ने checkbox अचयनित किया) अंतिम है और tool call पर मौजूद confirm: true इसे दरकिनार नहीं करता। confirm field के बिना स्वीकार किए जाने का अर्थ है कि client उपयोगी prompt नहीं दिखा पाया — confirm: true के साथ दोबारा प्रयास करके इसे ठीक किया जा सकता है
medium_write, high_write, destructive	नहीं	नहीं	रोकें (confirm: true के साथ दोबारा प्रयास करने का संकेत देते हुए error लौटाएँ)
medium_write, high_write, destructive	नहीं	हाँ	आगे बढ़ें (गैर-इंटरैक्टिव automation के लिए स्पष्ट opt-in)
कोई भी (या HARNESS_AUTO_APPROVE_RISK से कम)	कोई भी	कोई भी	बिना prompt के स्वतः स्वीकृत करें

यदि elicitInput किसी medium_write+ ऑपरेशन के लिए runtime पर विफल होता है (transport error, unsupported method), तो कॉल रोक दी जाती है, जब तक कि caller confirm: true पास न करे। confirm: true को fallback के रूप में तब माना जाता है, जब client prompt नहीं दिखा पाया या उसने अधूरी स्वीकृति लौटाई ({action: "accept"}, जिसमें confirm field नहीं है); लेकिन यह उस client की स्पष्ट अस्वीकृति/रद्द करने की कार्रवाई को नहीं बदलता, जिसने elicitation handshake पूरा किया हो।

स्वायत्त मोड

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

HARNESS_AUTO_APPROVE_RISK=all

यह deployment-स्तर की अधिकतम सीमा है: एक बार सेट हो जाने पर, अलग-अलग sessions इससे आगे नहीं जा सकते (हालाँकि वे x-harness-auto-approve-risk header के ज़रिए प्रति-session अधिक सख्त सीमा चुन सकते हैं)।

या अपने MCP client config में:

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

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

# 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	Reads + कम जोखिम वाले writes
medium_write	Reads + कम और मध्यम जोखिम वाले writes
high_write	Reads + कम, मध्यम और उच्च जोखिम वाले writes
all	सब कुछ, विनाशकारी ऑपरेशनों सहित

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

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

सुरक्षा

• Secrets कभी उजागर नहीं होते। secret resource type केवल metadata (name, type, scope) लौटाता है — किसी भी response में secret values शामिल नहीं होते।
• पुष्टि की आवश्यकता वाले ऑपरेशन उपलब्ध होने पर elicitation का उपयोग करते हैं। जब किसी write या execute कार्रवाई का जोखिम medium_write, high_write, या destructive हो, तो आगे बढ़ने से पहले harness_create, harness_update, harness_delete, और harness_execute MCP elicitation का प्रयास करते हैं (Elicitation देखें)। कम जोखिम वाली कार्रवाइयाँ (read, low_write — जैसे pipeline.create, pipeline.update, hql_query.run) बिना prompt के आगे बढ़ती हैं।
• मध्यम जोखिम और उससे ऊपर के ऑपरेशन सुरक्षित रूप से रोक दिए जाते हैं। यदि medium_write, high_write, या destructive ऑपरेशनों के लिए पुष्टि प्राप्त नहीं की जा सकती, तो उन्हें बिना सोचे-समझे चलाने के बजाय रोक दिया जाता है। स्वायत्त workflows के लिए HARNESS_AUTO_APPROVE_RISK से इसे override करें।
• CORS केवल same-origin तक सीमित है। HTTP transport केवल same-origin requests की अनुमति देता है, जिससे दुर्भावनापूर्ण वेबसाइटों द्वारा localhost पर MCP server को निशाना बनाकर किए जाने वाले CSRF हमले रुकते हैं।
• HTTP rate limiting। HTTP transport, request flooding रोकने के लिए प्रति IP 60 requests प्रति मिनट की सीमा लागू करता है।
• API rate limiting। Harness API client, upstream rate limits से बचने के लिए 10 requests/second की सीमा लागू करता है।
• पेजिनेशन की सीमाएँ लागू हैं। Memory exhaustion रोकने के लिए list queries कुल 10,000 items और प्रति page 100 items तक सीमित हैं।
• Backoff के साथ retries। अस्थायी विफलताओं (HTTP 429, 5xx) पर exponential backoff और jitter के साथ दोबारा प्रयास किया जाता है।
• Localhost पर binding। HTTP transport डिफ़ॉल्ट रूप से 127.0.0.1 से bind होता है — नेटवर्क से पहुँच योग्य नहीं।
• stdout पर कोई logging नहीं। stdio JSON-RPC transport को दूषित होने से बचाने के लिए सभी logs stderr पर जाते हैं।

पूरक Skills

Harness MCP server, Harness Skills के साथ अच्छी तरह काम करता है — यह सामान्य Harness workflows के लिए तैयार Claude Code skills (slash commands) का संग्रह है। इस MCP server के साथ इन्हें इंस्टॉल करें, ताकि custom prompts लिखे बिना /deploy, /rollback, /triage, और अन्य जैसी उच्च-स्तरीय automation मिल सके।

समस्या निवारण और आम समस्याएँ

लक्षण	संभावित कारण	क्या करें
HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...	API key समर्थित account-scoped फ़ॉर्मैट (pat.<accountId>... या sat.<accountId>...) में नहीं है, इसलिए account ID का अनुमान नहीं लगाया जा सकता	HARNESS_ACCOUNT_ID को स्पष्ट रूप से सेट करें
स्टार्टअप पर Unknown transport: "..."	CLI transport arg समर्थित नहीं है	केवल stdio या http का उपयोग करें
स्टार्टअप पर Invalid HARNESS_TOOLSETS: ...	एक या अधिक toolset नाम पहचाने नहीं गए	Toolset Filtering से केवल नामों का उपयोग करें (सटीक मिलान)
HTTP mcp-session-id header is required...	session header के बिना session अनुरोध भेजा गया	पहले initialize भेजें, फिर POST/GET/DELETE /mcp पर mcp-session-id शामिल करें
HTTP Session not found...	MCP_SESSION_TTL_MS निष्क्रिय मिलीसेकंड के बाद session की समय-सीमा समाप्त हो गई या वह पहले ही बंद हो चुका है	नया session बनाने के लिए initialize फिर से चलाएँ, फिर नए header के साथ दोबारा प्रयास करें
/mcp पर HTTP 405 Method Not Allowed	MCP endpoint के लिए method समर्थित नहीं है	केवल POST, GET, DELETE, या OPTIONS का उपयोग करें
HTTP Invalid request	JSON body अमान्य है या अनुरोध body HARNESS_MAX_BODY_SIZE_MB से बड़ी है	JSON payload के आकार/संरचना की पुष्टि करें; ज़रूरत पड़ने पर HARNESS_MAX_BODY_SIZE_MB बढ़ाएँ
tools से Unknown resource_type "..."	Resource type की वर्तनी गलत है या उसे HARNESS_TOOLSETS के ज़रिए फ़िल्टर किया गया है	मान्य types खोजने के लिए harness_describe कॉल करें (वैकल्पिक search_term के साथ)
Missing required field "... for path parameter ..."	project/org-scoped कॉल में identifiers मौजूद नहीं हैं	HARNESS_ORG/HARNESS_PROJECT सेट करें या हर tool call के साथ org_id/project_id पास करें
resource_scope "org" requires org_id... या resource_scope "project" requires project_id...	पर्याप्त identifiers के बिना multi-scope resource को org/project scope पर बाध्य किया गया	अनुपलब्ध 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 को रोकता है	यदि write operations अपेक्षित हैं, तो HARNESS_READ_ONLY=false सेट करें
Pipeline run pre-flight में आवश्यक inputs अनसुलझे होने के कारण विफल होता है	दिए गए inputs में आवश्यक runtime placeholders शामिल नहीं थे	runtime_input_template प्राप्त करें, अनुपलब्ध simple keys दें, या structural inputs के लिए input_set_ids का उपयोग करें
Pipeline CI shorthand (branch, tag, pr_number, commit_sha) लागू नहीं हुआ	inputs.build पहले से दिया गया था, इसलिए shorthand विस्तार जानबूझकर छोड़ दिया गया	shorthand विस्तार के लिए inputs.build हटाएँ, या पूरी स्पष्ट build संरचना बनाए रखें
Pipeline run ने गलत YAML revision लोड किया	Pipeline definition Git में संग्रहीत है और run में इच्छित pipeline branch निर्दिष्ट नहीं की गई	run action पर params.pipeline_branch पास करें; यह Harness branch से मैप होता है
wait: true ने _wait.error लौटाया	Pipeline trigger सफल हुआ, लेकिन server-side polling विफल रही	दोबारा चलाने का निर्णय लेने से पहले harness_get(resource_type="execution", ...) के साथ execution_id फिर जाँचें
wait: true ने execution_timed_out: true लौटाया	Execution, wait_timeout_seconds से पहले terminal status तक नहीं पहुँचा	स्थिति फिर जाँचने के लिए लौटाए गए execution_id का उपयोग करें; harness_diagnose चलाने से पहले terminal status की प्रतीक्षा करें
Execution logs खाली हैं या blob downloads 403 लौटाते हैं	Harness-hosted log blob URLs के लिए कॉन्फ़िगर किया गया Harness client/auth path आवश्यक है, विशेषकर internal या self-managed hosts के लिए	HARNESS_BASE_URL को target Harness host पर इंगित रखें और MCP client को bypass करने के बजाय harness_get(resource_type="execution_log", ...) या harness_diagnose(..., include_logs=true) का उपयोग करें
Operation declined by user / Operation cancelled by user	उपयोगकर्ता ने elicitation confirmation dialog अस्वीकार किया या रद्द किया — यह निर्णायक है	उपयोगकर्ता के साथ operation के विवरण की पुष्टि करें; confirm: true स्पष्ट अस्वीकृति को बायपास नहीं करता। उपयोगकर्ता को prompt स्वीकार करना होगा
Operation blocked: the client could not surface a usable confirmation prompt	Client में elicitation support नहीं है, elicitInput विफल हुआ, या उसने degenerate accept लौटाया	non-interactive automation के लिए confirm: true के साथ फिर प्रयास करें, या elicitation समर्थित करने वाला client उपयोग करें
template create/update के लिए body.template_yaml (or body.yaml) is required	Template APIs को पूरा YAML payload चाहिए	body में पूरी template_yaml string दें; deletes के लिए, एक version हटाने हेतु version_label पास करें (सभी versions हटाने के लिए इसे छोड़ दें)
स्टार्टअप पर HARNESS_BASE_URL must use HTTPS	HARNESS_BASE_URL HTTP URL पर सेट है	HTTPS का उपयोग करें, या local development के लिए HARNESS_ALLOW_HTTP=true सेट करें

लाइसेंस

MIT