Harness

Harness MCP Server 2.0

Ein MCP-Server (Model Context Protocol), der KI-Agenten über 11 zusammengefasste Tools und 274 Ressourcentypen vollständigen Zugriff auf die Harness.io-Plattform bietet.

Warum diesen MCP-Server verwenden?

Die meisten MCP-Server ordnen jedem API-Endpunkt ein Tool zu. Bei einer so umfangreichen Plattform wie Harness bedeutet das mehr als 240 Tools – und LLMs wählen mit steigender Anzahl immer schlechter das passende Tool aus. Kontextfenster füllen sich mit Schemas, und jeder neue Endpunkt erfordert neuen Code.

Dieser Server ist anders aufgebaut:

• 11 Tools, 274 Ressourcentypen. Ein registrierungsbasiertes Dispatch-System leitet harness_list, harness_get, harness_create usw. an beliebige Harness-Ressourcen weiter – Pipelines, Services, Umgebungen, Organisationen, Projekte, Feature Flags, Kostendaten und mehr. Das LLM wählt aus 11 Tools statt aus Hunderten.
• Vollständige Plattformabdeckung. 44 standardmäßige Toolsets für 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 und mehr. Bei Bedarf sind Ansible- und Observability-Evaluierungsfunktionen optional verfügbar.
• Workflows über mehrere Projekte hinweg sofort einsatzbereit. Agenten ermitteln Organisationen und Projekte dynamisch – hartcodierte Umgebungsvariablen sind nicht erforderlich. Bei der Anfrage „Zeige fehlgeschlagene Ausführungen in allen Projekten“ kann der Agent die gesamte Kontohierarchie durchlaufen.
• 35 Prompt-Vorlagen. Vorgefertigte Prompts für gängige Workflows: Apps von Anfang bis Ende erstellen und bereitstellen, fehlgeschlagene Pipelines debuggen, DORA-Metriken überprüfen, Schwachstellen priorisieren, Cloud-Kosten optimieren, Zugriffskontrollen prüfen, Feature-Flag-Rollouts planen, Pull Requests überprüfen, ausstehende Pipelines genehmigen und mehr.
• Funktioniert überall. Stdio-Transport für lokale Clients (Claude Desktop, Cursor, Devin Desktop), HTTP-Transport für Remote- und gemeinsam genutzte Bereitstellungen, bereit für Docker und Kubernetes.
• Start ohne Konfiguration. Es genügt, einen Harness-API-Schlüssel bereitzustellen. Die Konto-ID wird automatisch aus PAT- und SAT-Tokens extrahiert, Organisations- und Projektvorgaben sind optional, und durch Filtern der Toolsets werden nur die benötigten Funktionen bereitgestellt.
• Von Grund auf erweiterbar. Zum Hinzufügen einer neuen Harness-Ressource genügt eine deklarative Datendatei – es sind weder neue Toolregistrierungen noch Schemaänderungen oder Prompt-Aktualisierungen erforderlich.

Voraussetzungen

Bevor Sie den Server installieren oder ausführen, benötigen Sie einen Harness-API-Schlüssel:

1. Melden Sie sich bei Ihrem Harness-Konto an.
2. Gehen Sie zu My Profile → API Keys → + New API Key.
3. Erstellen Sie unter dem API-Schlüssel ein neues Token – dadurch wird ein PAT oder SAT im Format <prefix>.<accountId>.<tokenId>.<secret> generiert.
4. Speichern Sie das Token an einem sicheren Ort – Sie benötigen es im nächsten Schritt.

Eine ausführliche Anleitung finden Sie im Harness API Quickstart.

Schnellstart

Option 0: Gehostetes Harness MCP

Wenn der gehostete MCP-Dienst für Ihr Harness-Konto aktiviert ist, können Clients, die Remote-MCP-Server unterstützen, direkt eine Verbindung zum verwalteten Endpunkt herstellen, anstatt den Server lokal auszuführen.

Wichtig: Der gehostete MCP-Dienst verwendet Harness Platform OAuth, nicht HARNESS_API_KEY. Außerdem muss er vor der Nutzung des Endpunkts für jedes Konto von Harness Support aktiviert und konfiguriert werden.

Konfigurationsbeispiele finden Sie unter Gehostetes Harness MCP.

Option 1: npx (empfohlen)

Keine Installation erforderlich – einfach ausführen:

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

Oder konfigurieren Sie den API-Schlüssel in Ihrem KI-Client (siehe unten unter Clientkonfiguration).

# 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

Hinweis: Die Konto-ID wird automatisch aus PAT- und SAT-Tokens (pat.<accountId>... oder sat.<accountId>...) extrahiert. Daher wird HARNESS_ACCOUNT_ID nur für API-Schlüssel ohne eingebetteten Kontoabschnitt benötigt.

Option 2: Globale Installation

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

Option 3: Aus dem Quellcode erstellen

Für Entwicklung oder Anpassungen:

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

Das MCPB-Bundle-Manifest befindet sich unter [mcp-directory/](mcp-directory/), und das 512×512-Bundle-Symbol wird im Repository-Stammverzeichnis unter [icon.png](icon.png) verwaltet. Das gepackte Archiv enthält die Dateien manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json im Stammverzeichnis sowie node_modules/ für die Produktionsumgebung.

Um das Archiv klein zu halten, erstellen Sie MCPB-Pakete aus einem Staging-Verzeichnis:

pnpm prepare:mcpb

Das Staging-Verzeichnis wird unter dist/mcpb/ erstellt. Die Produktionsabhängigkeiten werden mit dem flachen npm-Layout aus npm-shrinkwrap.json installiert. Die festgelegte offizielle MCPB-CLI validiert das Verzeichnis und erstellt dist/harness-mcp-server-<version>.mcpb.

Versions-Tags, die v*.*.* entsprechen, veröffentlichen dieses Bundle automatisch im zugehörigen GitHub Release. Um ein bestehendes Release nachträglich zu ergänzen, ohne npm erneut zu veröffentlichen, führen Sie den Workflow Release manuell mit der Eingabe release_tag aus (zum Beispiel v3.2.20). Der Workflow checkt genau diesen Tag aus und erstellt daraus das Bundle, bevor ausschließlich dessen versioniertes MCPB-Asset ersetzt wird.

CLI-Verwendung

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

Wenn nicht angegeben, ist der Transport standardmäßig stdio. Verwenden Sie http für Remote- oder gemeinsam genutzte Bereitstellungen.

HTTP-Transport

Im HTTP-Modus stellt der Server Folgendes bereit:

Endpunkt	Methode	Beschreibung
/mcp	POST	MCP-JSON-RPC-Endpunkt (Initialisierung und Sitzungsanfragen)
/mcp	GET	SSE-Stream für vom Server initiierte Nachrichten (Fortschritt, Rückfragen)
/mcp	DELETE	Eine aktive MCP-Sitzung beenden
/mcp	OPTIONS	CORS-Preflight
/health	GET	Zustandsprüfung – gibt { "status": "ok", "sessions": <count> } zurück
/.well-known/oauth-protected-resource	GET	RFC-9728-Metadaten im Modus oauth und oauth-proxy
/.well-known/oauth-protected-resource/mcp	GET	Pfadbezogene RFC-9728-Metadaten für die standardmäßige /mcp-Ressource
/.well-known/oauth-authorization-server	GET	RFC-8414-Metadaten des eingebetteten Brokers im Modus oauth-proxy
/oauth/authorize	GET	MCP-Client-Anmeldung über den vorgelagerten Anbieter und HarnessID starten
/oauth/upstream/callback	GET	Callback des vorgelagerten Identitätsanbieters
/oauth/harnessid/callback	GET	HarnessID-Anmelde-Callback
/oauth/token	POST	Vorgelagerte Tokens für den MCP-Client zurückgeben oder aktualisieren; HarnessID-Tokens werden niemals zurückgegeben

Der HTTP-Transport läuft im sitzungsbasierten Modus. Eine neue MCP-Sitzung wird bei initialize erstellt, der Server gibt einen mcp-session-id-Header zurück, und nachfolgende Anfragen für diese Sitzung müssen denselben Header enthalten.

Betriebliche Einschränkungen im HTTP-Modus:

• Legen Sie HARNESS_MCP_AUTH_TOKEN für gemeinsam genutzte oder remote erreichbare Einzelbenutzer- und Mehrbenutzerbereitstellungen fest. Wenn diese Variable gesetzt ist, muss jede Anfrage POST, GET und DELETE an /mcp den Header Authorization: Bearer <token> enthalten.
• Der OAuth-Modus akzeptiert HarnessID-Zugriffstokens anstelle von HARNESS_MCP_AUTH_TOKEN und kann ohne die Option zum Deaktivieren der Authentifizierung an eine Nicht-Loopback-Adresse gebunden werden.
• Der OAuth-Proxy-Modus akzeptiert ein Token des vorgelagerten Identitätsanbieters, tauscht es intern gegen ein benutzerspezifisches HarnessID-Token aus und erfordert das vorgelagerte Token bei jeder Anfrage.
• Bindungen für Einzelbenutzer- und Mehrbenutzerbereitstellungen an Nicht-Loopback-Adressen erfordern standardmäßig HARNESS_MCP_AUTH_TOKEN. Um dennoch unauthentifiziert auf einer Nicht-Loopback-Schnittstelle zu laufen, setzen Sie HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true ausdrücklich.
• POST /mcp ohne mcp-session-id muss eine Anfrage vom Typ initialize sein.
• POST /mcp, GET /mcp und DELETE /mcp für bestehende Sitzungen erfordern den Header mcp-session-id.
• GET /mcp wird für SSE-Benachrichtigungen verwendet (Fortschrittsaktualisierungen und Rückfragen).
• Inaktive Sitzungen werden nach MCP_SESSION_TTL_MS Millisekunden entfernt, sobald keine Anfrage und kein SSE-Stream aktiv ist (standardmäßig 1800000, also 30 Minuten).
• GET /health ist der einzige Nicht-MCP-Endpunkt.
• Die Größe des Anfrageinhalts ist durch HARNESS_MAX_BODY_SIZE_MB begrenzt (standardmäßig 10 MB).
• Setzen Sie x-harness-pipeline-version: 0 oder 1 in der Anfrage initialize, um V0- oder V1-Pipeline-Ressourcen für diese HTTP-Sitzung auszuwählen.
• Setzen Sie x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all in der Anfrage initialize, um einen strengeren Schwellenwert für die automatische Genehmigung pro Sitzung festzulegen. Der Server begrenzt diesen Wert auf den bereitstellungsweiten Wert HARNESS_AUTO_APPROVE_RISK, sodass eine Sitzung die konfigurierte Genehmigungsobergrenze senken, aber nicht erhöhen kann.

HarnessID-OAuth-Modus

Setzen Sie HARNESS_MCP_MODE=oauth, damit Remote-MCP-Clients HarnessID erkennen und OAuth 2.1 Authorization Code mit PKCE abschließen können. Der OAuth-Modus ist nur mit HTTP-Transport verfügbar. Die Produktionsstandards für HarnessID, MCP-Ressourcen und API-Routing sind integriert:

HARNESS_MCP_MODE=oauth

Standardmäßig werden der Aussteller https://id.harness.io/idp/realms/HarnessIDP, die Ressource https://mcp.harness.io/mcp, der OAuth-Client mcp-client und die Harness-API-Basis https://mcp.harness.io/cli verwendet. Überschreiben Sie diese Werte nur für QA, lokale Entwicklung oder eine andere Harness-Umgebung.

HARNESS_API_KEY darf in diesem Modus nicht gesetzt sein. HARNESS_MCP_OAUTH_JWKS_URI ist standardmäßig <issuer>/protocol/openid-connect/certs, und HARNESS_ACCOUNT_ID ist nicht erforderlich, da das Konto aus dem Token stammt. Wenn das optionale Toolset appsec (HARNESS_TOOLSETS=+appsec) aktiviert ist, müssen Sitzungen außerdem x-harness-appsec-api-key in der Anfrage initialize übergeben (HarnessID-OAuth-Tokens werden niemals an api.traceable.ai weitergeleitet).

Der Server veröffentlicht RFC-9728-Metadaten für geschützte Ressourcen und gibt die folgende Challenge zurück, wenn ein Client nicht authentifiziert ist:

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

Der Server validiert anhand des konfigurierten JWKS-Endpunkts die RS256-Signatur, iss, den Ablaufzeitpunkt und sub des HarnessID-Zugriffstokens. Außerdem prüft er über den Claim azp, ob das Token für HARNESS_MCP_OAUTH_CLIENT_ID ausgestellt wurde. HARNESS_MCP_OAUTH_RESOURCE ist der RFC-9728-Bezeichner der geschützten Ressource, der für Erkennung und Challenges verwendet wird. Aktuelle HarnessID-Zugriffstokens verwenden aud: account statt der MCP-URL, daher wird die Ressource nicht mit aud verglichen.

Die Konto-ID stammt aus dem Claim HARNESS_MCP_OAUTH_ACCOUNT_CLAIM des Tokens (standardmäßig account_id), der durch den HarnessID-Scope organization befüllt wird. Jede Sitzung speichert das Zugriffstoken des Aufrufers und leitet es als Authorization: Bearer an die Harness-API weiter, sodass Harness-RBAC und Audit-Datensätze den angemeldeten Benutzer statt eines gemeinsam genutzten PAT widerspiegeln. Die Sitzung ist an den sub und das Konto gebunden, mit denen sie erstellt wurde: Eine spätere Anfrage darf ein aktualisiertes Token enthalten, ein Token für einen anderen Benutzer oder ein anderes Konto wird jedoch abgelehnt.

Clients benötigen normalerweise nur die MCP-Ressourcen-URL:

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

Der Client liest die Metadaten der geschützten Ressource, ermittelt HARNESS_MCP_OAUTH_ISSUER und verwendet anschließend die RFC-8414-Metadaten dieses Autorisierungsservers. Wenn der Client keine dynamische Clientregistrierung unterstützt, verwenden Sie die vorregistrierte Client-ID mcp-client.

Eine Checkliste für QA mit Keycloak und Validierungsbefehle finden Sie unter HarnessID OAuth für einen selbst gehosteten MCP-Server.

OAuth-Proxy-Modus für vorgelagerte Identitätsanbieter

Der OAuth-Proxy-Modus benötigt einen vertraulichen HarnessID-Client. Das Harness-ID-Team erstellt diesen Client und stellt die Client-ID sowie das Client-Secret bereit. Wenden Sie sich an das Harness-ID-Team, bevor Sie diesen Modus aktivieren.

Setzen Sie HARNESS_MCP_MODE=oauth-proxy, wenn ein MCP-Client ausschließlich ein Token des vorgelagerten Identitätsanbieters besitzen soll. Der öffentliche Clientname kann beliebig sein. Setzen Sie HARNESS_MCP_BROKER_CLIENT_ID auf denselben Namen, den der MCP-Client verwendet. Der integrierte OAuth-Broker startet die Browseranmeldung beim vorgelagerten Anbieter, schließt die HarnessID-Anmeldung im selben Ablauf ab und gibt ausschließlich die vorgelagerten Zugriffs- und Aktualisierungstokens an den MCP-Client zurück. Bei jeder Anfrage /mcp validiert der Server das vorgelagerte Token und verwendet ein zwischengespeichertes benutzerspezifisches HarnessID-Zugriffstoken. Vor dessen Ablauf wird es mithilfe des Aktualisierungstokens erneuert. Fehlt die Zuordnung zwischen dem vorgelagerten Anbieter und HarnessID, wird 401 zurückgegeben, damit sich der Client erneut anmeldet. HarnessID-Tokens verbleiben auf dem Server. Aktualisierungstokens, zwischengespeicherte Zugriffstokens und temporäre OAuth-Zustandsdaten werden im Ruhezustand verschlüsselt. Dieser Modus unterstützt ausschließlich HTTP. Außerdem benötigt er den Upstream-Issuer und die Audience sowie einen stabilen 32-Byte-Vault-Schlüssel. Informationen zur Konfiguration und zu MCP-End-to-End-Testbefehlen findest du unter Upstream identity provider OAuth proxy mode.

Mehrbenutzermodus

Setze HARNESS_MCP_MODE=multi-user für gemeinsam genutzte HTTP-Bereitstellungen, bei denen sich jeder Client als ein anderer Harness-Benutzer authentifiziert. In diesem Modus gilt:

• HARNESS_API_KEY darf nicht in der Serverkonfiguration gesetzt sein — der Server besitzt keine Harness-Anmeldedaten.
• Jede Sitzung muss x-harness-api-key bei der Anfrage initialize bereitstellen. x-harness-account-id ist nur erforderlich, wenn der API-Schlüssel kein Account-Segment enthält.
• Sitzungen können außerdem die Header x-harness-org und x-harness-project bereitstellen, um den Standard-Scope für die jeweilige Sitzung festzulegen.
• Wenn das optionale Toolset appsec (HARNESS_TOOLSETS=+appsec) aktiviert ist, müssen Sitzungen, die appsec_*-Ressourcen aufrufen, außerdem x-harness-appsec-api-key bei der Anfrage initialize bereitstellen (x-harness-api-key der Sitzung wird niemals an api.traceable.ai weitergeleitet).
• Der Harness-API-Schlüssel wird für jede Harness-API-Anfrage der Sitzung verwendet, sodass der Audit-Trail in Harness den tatsächlichen Benutzer widerspiegelt.
• HARNESS_MCP_AUTH_TOKEN ist davon unabhängig und kann weiterhin als zusätzliche Transportschicht-Schranke verwendet werden.

# 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 steuert die Validierung des Host-Headers zum Schutz vor DNS-Rebinding, und CORS schränkt Browser-Ursprünge ein. Beides dient nicht der Authentifizierung; verwende HARNESS_MCP_AUTH_TOKEN oder ein authentifiziertes Gateway/einen Reverse-Proxy zur Zugriffskontrolle.

Clientkonfiguration

Hinweis: HARNESS_ORG und HARNESS_PROJECT sind optional. Sie legen die Organisations-ID und Projekt-ID fest, die verwendet werden, wenn sie nicht pro Tool-Aufruf angegeben werden. Agents können Organisationen und Projekte dynamisch mit harness_list(resource_type="organization") und harness_list(resource_type="project") ermitteln. Die veralteten Namen HARNESS_DEFAULT_ORG_ID und HARNESS_DEFAULT_PROJECT_ID werden aus Gründen der Abwärtskompatibilität weiterhin akzeptiert.

Gehostetes Harness MCP

Harness unterstützt außerdem einen gehosteten MCP-Endpunkt für Konten, bei denen der verwaltete Dienst aktiviert ist. Das ist nützlich, wenn du einen gemeinsam genutzten Remote-MCP-Endpunkt verwenden möchtest, statt npx harness-mcp-v2 auszuführen oder den HTTP-Transport selbst zu hosten.

Wichtig: Die Authentifizierung für gehostetes MCP verwendet Harness Platform OAuth. In der Clientkonfiguration wird nicht HARNESS_API_KEY verwendet. Die Verfügbarkeit von gehostetem MCP wird pro Harness-Konto konfiguriert. Daher musst du dich an den Harness Support wenden, um die Einstellung vor der Verwendung aktivieren/konfigurieren zu lassen.

Der gehostete Endpunkt https://mcp.harness.io/mcp ist ein verwalteter Dienst. Die MCP-Clientkonfiguration in Claude, Cursor oder Cowork kann nicht überschreiben, an welche Harness-Umgebung er weiterleitet. Für Harness0 oder eine andere private Harness-SaaS-Umgebung bitte den Harness Support, gehostetes MCP für diese Umgebung zu aktivieren/konfigurieren, oder führe den lokalen/selbst gehosteten Server aus und setze HARNESS_BASE_URL auf den gewünschten Harness-Host.

Beispiel für gehostetes MCP:

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

Beispiel mit gehosteten und lokalen Einträgen:

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

Fehlerbehebung bei npx ENOENT oder node: No such file or directory

Dies ist ein Fehler beim Starten des Clientprozesses, kein Harness-Authentifizierungsfehler. Der MCP-Server wurde noch nicht gestartet, daher wirkt sich eine Änderung von HARNESS_API_KEY nicht auf spawn npx ENOENT aus.

GUI-Apps (Cursor, Claude Desktop, Devin Desktop, VS Code) übernehmen nicht immer die PATH deiner Shell. Daher finden sie nach dem Neuladen der Konfiguration möglicherweise npx oder node nicht. Verwende absolute Pfade und setze PATH explizit im Block env, um das Problem zu beheben:

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

Ermittle deine Pfade in einem Terminal mit which npx und which node. Stelle anschließend sicher, dass das Verzeichnis mit node im obigen Wert für PATH enthalten ist. Häufige Speicherorte:

• Homebrew (macOS): /opt/homebrew/bin/npx
• nvm: ~/.nvm/versions/node/v20.x.x/bin/npx (führe nvm which current aus, um den genauen Pfad zu ermitteln)
• System-Node: /usr/local/bin/npx

Claude Desktop (claude_desktop_config.json)

npx (keine Installation erforderlich)

{
  "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 (lokale Installation)

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

npx (keine Installation erforderlich)

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

node (lokale Installation)

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

Setze anschließend HARNESS_API_KEY in deiner Umgebung oder in der Datei .env.

Cursor (.cursor/mcp.json)

npx (keine Installation erforderlich, für lokale Cursor-Konfigurationen empfohlen)

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

Führe which npx in einem Terminal aus und verwende den vollständigen Pfad als command; füge das Verzeichnis aus which node am Anfang von PATH ein.

node (lokale Installation)

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

Führe which harness-mcp-v2 nach npm install -g harness-mcp-v2 aus und verwende den vollständigen Pfad als command; füge das Verzeichnis aus which node am Anfang von PATH ein.

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

npx (keine Installation erforderlich)

{
  "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 (lokale Installation)

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

Verwendest du einen lokalen Build aus dem Quellcode?

Ersetze den Befehl durch den Pfad zu deinem erstellten index.js:

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

MCP-Gateway

Der Harness-MCP-Server ist vollständig mit MCP-Gateways kompatibel — Reverse-Proxys, die zentrale Authentifizierung, Governance, Tool-Routing und Beobachtbarkeit für mehrere MCP-Server bereitstellen. Da der Server das standardisierte MCP-Protokoll mit stdio- und HTTP-Transport implementiert, funktioniert er ohne Codeänderungen hinter jedem MCP-kompatiblen Gateway.

Warum ein Gateway verwenden?

• Zentrale Verwaltung von Anmeldedaten — keine API-Schlüssel in Agent-Konfigurationen
• Governance und Audit-Protokollierung für alle Tool-Aufrufe teamübergreifend
• Ein einziger Endpunkt für Agents statt N Verbindungen zu N MCP-Servern
• Zugriffskontrolle — einschränken, welche Teams welche Tools verwenden können

Docker MCP Gateway

Registriere den Server in deiner Docker-MCP-Gateway-Konfiguration:

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

Portkey

Füge den Harness-MCP-Server zu deinem Portkey MCP Gateway hinzu, um Governance für Unternehmen, Kostenverfolgung und Multi-LLM-Routing zu ermöglichen:

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

LiteLLM

Füge ihn zu deiner LiteLLM proxy config hinzu:

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

Envoy AI Gateway

Der Server funktioniert über den HTTP-Transport mit der MCP-Unterstützung von Envoy AI Gateway:

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

Konfiguriere Envoy anschließend so, dass es http://localhost:8080/mcp als Upstream-MCP-Backend verwendet.

Kong

Verwende das AI MCP Proxy-Plugin von Kong, um den Harness-MCP-Server über deine bestehende Kong-Gateway-Infrastruktur bereitzustellen.

Andere Gateways

Jedes Gateway, das die MCP-Spezifikation unterstützt (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers usw.), kann diesen Server als Proxy verwenden. Verwende für Gateways mit stdio-Transport den Standardtransport. Starte den Server für Gateways mit HTTP-Transport mit dem Transport http und verweise das Gateway auf den Endpunkt /mcp.

Docker

Erstelle ein Docker-Image des Servers und führe ihn als Container aus:

# 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

Der Container läuft standardmäßig im HTTP-Modus auf Port 3000 und verfügt über eine integrierte Zustandsprüfung.

Kubernetes

Stelle den Server mithilfe der bereitgestellten Manifeste in einem Kubernetes-Cluster bereit:

# 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

Die Bereitstellung umfasst 2 Replikate mit Readiness-/Liveness-Probes, Ressourcenlimits und einem Sicherheitskontext ohne Root-Rechte. Der Service stellt intern Port 80 bereit (mit Ziel auf Container-Port 3000).

Konfiguration

Der Server lädt automatisch Umgebungsvariablen aus einer Datei .env im Projektstammverzeichnis, sofern eine vorhanden ist. Kopiere .env.example nach .env und trage deine Werte ein. Umgebungsvariablen können auch über deine Shell oder die MCP-Clientkonfiguration gesetzt werden.

Variable	Erforderlich	Standardwert	Beschreibung
HARNESS_MCP_MODE	Nein	single-user	Bereitstellungsmodus: single-user, multi-user, oauth (direktes HarnessID-Token) oder oauth-proxy (Upstream-Identitätsanbieter-Token, das gegen ein benutzerspezifisches HarnessID-Token ausgetauscht wird)
HARNESS_API_KEY	Ja*	--	Persönliches Harness-Zugriffstoken oder Dienstkontotoken. Im Modus single-user erforderlich. Darf im Modus multi-user, oauth oder oauth-proxy NICHT gesetzt sein, da jede Sitzung ihre eigenen Anmeldedaten mitbringt
HARNESS_ACCOUNT_ID	Nein	(aus PAT/SAT)	Harness-Konto-ID. Wird im Einzelbenutzermodus automatisch aus PAT/SAT-Tokens extrahiert; Sitzungen mit mehreren Benutzern können ihre eigene ID über x-harness-account-id angeben, wenn der API-Schlüssel keine enthält
HARNESS_BASE_URL	Nein	https://app.harness.io (https://mcp.harness.io/cli in oauth und oauth-proxy)	Harness-API-/UI-Basis-URL. oauth und oauth-proxy werden standardmäßig über den gehosteten MCP-Proxy /cli geleitet; andere Modi verwenden direkt die Harness-SaaS-API
HARNESS_MCP_OAUTH_ISSUER	Nein	https://id.harness.io/idp/realms/HarnessIDP	HarnessID-Aussteller, der exakt mit dem iss-Claim des Zugriffstokens abgeglichen wird
HARNESS_MCP_OAUTH_RESOURCE	Nein	https://mcp.harness.io/mcp	Öffentliche kanonische MCP-URL, die als Ressourcenkennung gemäß RFC 9728 veröffentlicht wird
HARNESS_MCP_OAUTH_JWKS_URI	Nein	<issuer>/protocol/openid-connect/certs	HarnessID-JWKS-Endpunkt zur Validierung von RS256-Zugriffstokensignaturen
HARNESS_MCP_OAUTH_CLIENT_ID	Nein	mcp-client	HarnessID-Client, für den das Zugriffstoken ausgestellt sein muss; Abgleich mit dem azp-Claim des Tokens
HARNESS_MCP_OAUTH_ACCOUNT_CLAIM	Nein	account_id	Claim des Zugriffstokens, der die Harness-Konto-ID enthält und durch den HarnessID-Bereich organization befüllt wird
HARNESS_MCP_OAUTH_SCOPES	Nein	openid profile email organization	Durch Leerzeichen getrennte Bereiche, die in den geschützten Ressourcenmetadaten gemäß RFC 9728 angekündigt werden
HARNESS_MCP_OAUTH_CLIENT_SECRET	Ja*	--	Vertrauliches HarnessID-Clientgeheimnis, das vom Harness-ID-Team ausgestellt wird; nur im Modus oauth-proxy erforderlich
HARNESS_MCP_OAUTH_EXTERNAL_SUB_CLAIM	Nein	external_sub	HarnessID-Token-Claim, der beim Verknüpfen mit dem Upstream-Subjekt oder der Upstream-E-Mail-Adresse abgeglichen wird
HARNESS_MCP_OAUTH_PROXY_GRANT	Nein	refresh	Berechtigung für spätere Anfragen im Modus oauth-proxy: refresh oder jwt-bearer
HARNESS_MCP_OAUTH_PROXY_PUBLIC_URL	Ja*	--	Öffentlicher Ursprung des OAuth-Brokers. Im Modus oauth-proxy erforderlich und muss denselben Ursprung wie HARNESS_MCP_OAUTH_RESOURCE haben
HARNESS_MCP_OAUTH_PROXY_VAULT_MODE	Nein	file	file speichert den verschlüsselten Tresor lokal auf der Festplatte eines Pods. redis teilt Aktualisierungstokens und Anmeldestatus podübergreifend
HARNESS_MCP_OAUTH_PROXY_VAULT_PATH	Nein	.harness-mcp/oauth-proxy-vault.enc	Verschlüsseltes HarnessID-Token und Anmeldestatusdatei, die verwendet werden, wenn der Tresormodus file ist
HARNESS_MCP_OAUTH_PROXY_VAULT_KEY	Ja*	--	Base64-kodierter 32-Byte-AES-Schlüssel, der im Modus oauth-proxy erforderlich ist
HARNESS_MCP_OAUTH_PROXY_REDIS_URL	Ja*	--	rediss://-URL, erforderlich, wenn der Tresormodus redis ist. redis:// erfordert HARNESS_ALLOW_HTTP=true. Redis 6.2 oder neuer
HARNESS_MCP_OAUTH_PROXY_REDIS_KEY_PREFIX	Nein	harness-mcp:oauth	Präfix für OAuth-Tresorschlüssel in Redis
HARNESS_MCP_UPSTREAM_ISSUER	Ja*	--	Exakter Upstream-Token-Aussteller, erforderlich im Modus oauth-proxy
HARNESS_MCP_UPSTREAM_AUDIENCE	Ja*	--	Exakte Upstream-Token-Zielgruppe, erforderlich im Modus oauth-proxy
HARNESS_MCP_UPSTREAM_JWKS_URI	Nein	<upstream issuer>/v1/keys	Upstream-RS256-JWKS-Endpunkt
HARNESS_MCP_UPSTREAM_SCOPES	Nein	openid profile email offline_access	Vom eingebetteten Broker angeforderte und dem MCP-Client mitgeteilte Bereiche
HARNESS_MCP_UPSTREAM_OAUTH_CLIENT_ID	Ja*	--	Vertraulicher Upstream-OAuth-Client, der vom eingebetteten Broker verwendet wird
HARNESS_MCP_UPSTREAM_OAUTH_CLIENT_SECRET	Ja*	--	Upstream-OAuth-Clientgeheimnis, das nur vom Server verwendet wird
HARNESS_MCP_UPSTREAM_DISCOVERY_URI	Nein	<upstream issuer>/.well-known/openid-configuration	Upstream-OIDC-Erkennungsendpunkt
HARNESS_MCP_UPSTREAM_EMAIL_DOMAINS	Nein	--	Durch Kommas getrennte Domains. Die Verknüpfung per E-Mail erfordert email_verified=true und eine Domain aus dieser Liste. Bei einer leeren Liste erfolgt keine Verknüpfung per E-Mail
HARNESS_MCP_BROKER_ISSUER	Nein	Öffentliche URL des OAuth-Proxys	Aussteller des Autorisierungsservers, den der MCP-Client ermittelt
HARNESS_MCP_BROKER_CLIENT_ID	Nein	cursor-harness-mcp	Öffentliche OAuth-Client-ID. Jeder Name ist zulässig, wenn der MCP-Client mit demselben Wert konfiguriert ist
HARNESS_MCP_BROKER_REDIRECT_URIS	Nein	(leer)	Durch Kommas getrennte Umleitungs-URIs. Bei leerem Wert werden alle Rückrufe abgelehnt. * erlaubt nur Loopback-http/https. Benutzerdefinierte Schemas müssen exakt aufgeführt sein
HARNESS_MCP_BROKER_CODE_TTL_MS	Nein	60000	Gültigkeitsdauer einmaliger Autorisierungscodes, die dem MCP-Client ausgestellt werden
HARNESS_MCP_BROKER_TRANSACTION_TTL_MS	Nein	600000	Maximale Gültigkeitsdauer der verketteten Browser-Autorisierungstransaktion
HARNESS_FME_API_KEY	Nein	--	Optionaler FME-/Split-Admin-Anmeldenachweis für Einzelbenutzer/Self-Hosting, der nur für fme_-Ressourcen im Legacy-Modus (workspace_id) verwendet wird. Legacy-FME ist im OAuth-Modus nicht verfügbar, daher werden HarnessID-Tokens niemals an api.split.io gesendet; verwenden Sie stattdessen den Harness-nativen Bereich org_id+project_id. Darf nicht im Modus multi-user, oauth oder oauth-proxy gesetzt sein
HARNESS_FME_BASE_URL	Nein	https://api.split.io	Basis-URL der Split-/FME-Admin-API, die nur von fme_-Ressourcen im Legacy-Modus (workspace_id) verwendet wird. HTTP-URLs erfordern HARNESS_ALLOW_HTTP=true für die lokale Entwicklung. Der Harness-native Modus (org_id+project_id) ignoriert diesen Wert und verwendet stattdessen den Standardwert HARNESS_API_KEY/HARNESS_BASE_URL
HARNESS_APPSEC_API_KEY	Nein	--	Optionales Traceable-Platform-API-Token für Einzelbenutzer, das von appsec_-Ressourcen (HARNESS_TOOLSETS=+appsec) verwendet wird. HARNESS_API_KEY, Sitzungs-x-harness-api-key und HarnessID-OAuth-Tokens werden niemals an Traceable weitergeleitet. Darf nicht im Modus multi-user, oauth oder oauth-proxy gesetzt sein (gehostete Sitzungen stellen x-harness-appsec-api-key pro Sitzung bereit)
HARNESS_APPSEC_BASE_URL	Nein	https://api.traceable.ai	Basis-URL der Traceable-GraphQL-API, die von appsec_-Ressourcen verwendet wird. HTTP-URLs erfordern HARNESS_ALLOW_HTTP=true für die lokale Entwicklung
HARNESS_APPSEC_UI_URL	Nein	https://app.traceable.ai	Basis-URL der Traceable-Weboberfläche für Deeplinks in appsec_-Ressourcen (wird abgeleitet von HARNESS_APPSEC_BASE_URL, wenn nicht festgelegt)
HARNESS_ORG	Nein	--	Organisations-ID. Wird verwendet, wenn org_id nicht pro Toolaufruf angegeben ist. Wenn sie fehlt, muss org_id explizit angegeben werden. Agents können Organisationen auch dynamisch über harness_list(resource_type="organization") ermitteln
HARNESS_PROJECT	Nein	--	Projekt-ID. Wird verwendet, wenn project_id nicht pro Toolaufruf angegeben ist. Agents können Projekte auch dynamisch über harness_list(resource_type="project") ermitteln
HARNESS_API_TIMEOUT_MS	Nein	30000	HTTP-Anfrage-Timeout in Millisekunden
HARNESS_MAX_RETRIES	Nein	3	Anzahl der Wiederholungsversuche bei vorübergehenden Fehlern (429, 5xx)
HARNESS_MAX_BODY_SIZE_MB	Nein	10	Maximale Größe des HTTP-Anfrageinhalts in MB für den Transport http
HARNESS_RATE_LIMIT_RPS	Nein	10	Clientseitige Anfragedrosselung (Anfragen pro Sekunde) an Harness-APIs
LOG_LEVEL	Nein	info	Ausführlichkeit der Protokollierung: debug, info, warn, error
HARNESS_TOOLSETS	Nein	(Standardwerte)	Durch Kommas getrennte Toolset-Liste. Bei leerem Wert werden die Standard-Toolsets geladen. Unterstützt +name zum expliziten Einschließen optionaler Toolsets und -name zum Entfernen von Standardwerten (siehe Toolset-Filterung)
HARNESS_READ_ONLY	Nein	false	Alle ändernden Vorgänge (Erstellen, Aktualisieren, Löschen, Ausführen) blockieren. Nur Auflisten und Abrufen sind zulässig. Nützlich für gemeinsam genutzte/Demo-Umgebungen
HARNESS_SCHEMA_MODE	Nein	compact	compact (Standard) oder full. Im kompakten Modus wird die Ressourcenart-Aufzählung pro Tool durch eine einfache Zeichenfolge ersetzt und die Feldbeschreibung gekürzt. Dadurch wird die an das Modell gesendete Toolliste etwa halbiert (siehe docs/schema-budget.md). Die Typen werden über harness_describe ermittelt. Legen Sie full fest, um alle Ressourcentypen inline einzufügen.
HARNESS_MCP_APPS	Nein	off	MCP-Apps-Ansichten. off (Standard) behält reine Textergebnisse bei. auto stellt die Ressource ui://harness/app bereit und fügt Ansichtsdatendaten nur zu den Ergebnissen von harness_get, harness_execute und harness_status hinzu, und zwar nur für Hosts, die die Erweiterung io.modelcontextprotocol/ui deklarieren; andere Clients erhalten weiterhin unveränderte Textergebnisse
HARNESS_AUTO_APPROVE_RISK	Nein	none	Risikobasierter Schwellenwert für die automatische Genehmigung autonomer Workflows. Vorgänge mit einem Risiko unter oder auf diesem Schwellenwert werden ohne Bestätigung ausgeführt. Werte: none, low_write, medium_write, high_write, all. Siehe Elicitation
HARNESS_SKIP_ELICITATION	Nein	false	Veraltet — stattdessen HARNESS_AUTO_APPROVE_RISK=all verwenden. Aus Gründen der Abwärtskompatibilität beibehalten
HARNESS_ALLOW_HTTP	Nein	false	Nicht-HTTPS-HARNESS_BASE_URL zulassen. Standardmäßig erzwingt der Server aus Sicherheitsgründen HTTPS. Nur für die lokale Entwicklung mit einer nicht-TLS-fähigen Harness-Instanz auf true setzen
HARNESS_PIPELINE_VERSION	Nein	0	(Alpha) Pipeline-YAML-Version. 0 lädt den Ressourcentyp pipeline und schließt pipeline_v1 aus; 1 lädt pipeline_v1 und schließt pipeline aus. HTTP-Sitzungen können dies beim Initialisieren mit x-harness-pipeline-version: 0 oder 1 überschreiben
HARNESS_MCP_ALLOWED_HOSTS	Nein	--	Durch Kommas getrennte Hostnamen, die bei der Host-Header-Validierung des HTTP-Transports zulässig sind. mcp.harness.io ist standardmäßig für Localhost-Bindings zulässig; Proxy- und benutzerdefinierte Domains hier hinzufügen
HARNESS_MCP_AUTH_TOKEN	Nein	--	Statisches Bearer-Token, das bei entsprechender Konfiguration für /mcp-HTTP-Routen erforderlich ist. Standardmäßig für Single-User- und Multi-User-Bindings außerhalb des Loopbacks erforderlich. Muss im Modus oauth nicht gesetzt sein
HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP	Nein	false	Nicht authentifizierten HTTP-Transport für Bindings außerhalb des Loopbacks ausdrücklich zulassen. Nur hinter einer anderen authentifizierten Steuerung verwenden
HARNESS_MCP_TRUST_PROXY	Nein	0	Anzahl der Reverse-Proxy-/Load-Balancer-Hops, denen bei der Auflösung der Client-IP vertraut wird (Express trust proxy). Auf die Anzahl der Proxys vor dem Server setzen, damit die Ratenbegrenzung pro IP die tatsächliche Client-IP statt des Proxy-Socket-Peers verwendet
HARNESS_MCP_LOG_FILE	Nein	~/.claude/harness-mcp.log	Datei für Diagnoseinformationen bei Verbindungsabbrüchen oder Abstürzen über stdio, wenn stderr möglicherweise nicht mehr verfügbar ist
HARNESS_LOG_UNSAFE_BODIES	Nein	false	Rohe Request-/Response-Bodies in Logs aufnehmen. Standardmäßig deaktiviert, da Bodies Geheimnisse enthalten können; nur für lokales Debugging aktivieren
HARNESS_AUDIT_FILE	Nein	--	Audit-Ereignisse zur dauerhaften lokalen Erfassung an eine JSON-Datei mit einer Zeile pro Eintrag anhängen
HARNESS_AUDIT_WEBHOOK_URL	Nein	--	HTTPS-Endpunkt, der gebündelte Audit-Ereignisse empfängt. Für lokale Entwicklung ist bei HTTP-URLs HARNESS_ALLOW_HTTP=true erforderlich
HARNESS_AUDIT_WEBHOOK_TOKEN	Nein	--	Optionales Bearer-Token, das an den Audit-Webhook gesendet wird
HARNESS_AUDIT_WEBHOOK_BATCH_SIZE	Nein	10	Anzahl der Audit-Ereignisse, die vor dem Senden eines Webhook-Batches gesammelt werden
HARNESS_AUDIT_WEBHOOK_FLUSH_MS	Nein	5000	Maximale Zeit, die Audit-Ereignisse vor dem Senden eines Webhook-Batches zurückgehalten werden
OTEL_EXPORTER_OTLP_ENDPOINT	Nein	--	Aktiviert OpenTelemetry-Audit-Spans, wenn die optionalen OpenTelemetry-Pakete installiert sind
HARNESS_SEARCH_PROVIDER	Nein	local	Backend für die semantische Suche: local (ONNX-Embeddings im Prozess, Standard), remote (externer Suchdienst über HTTP, erforderlich für den Multi-User-Modus) oder none (semantische Suche deaktivieren und nur Keyword-Scatter-Gather verwenden). In Air-Gap-Umgebungen oder wenn das Laden des Modells beim Start unerwünscht ist, none verwenden
HARNESS_SEARCH_SERVICE_URL	Nein	--	Basis-URL des Remote-Suchdienstes, wenn HARNESS_SEARCH_PROVIDER=remote (z. B. http://search-svc:8080). Erforderlich bei Verwendung des Providers remote
HARNESS_SEARCH_SERVICE_HEADERS	Nein	--	JSON-Objekt mit Headern, die bei jeder Anfrage an den Remote-Suchdienst gesendet werden. Unterstützt beliebige Authentifizierungsschemata: {"Authorization":"Bearer tok"}, {"x-api-key":"key"} oder mehrere interne Service-zu-Service-Header
HARNESS_HF_CACHE_DIR	Nein	/tmp/hf-cache	Verzeichnis für den @huggingface/transformers-Modellcache, der vom Suchprovider local verwendet wird. Das Docker-Image enthält das Modell bereits unter /app/.cache/hf, um Downloads zur Laufzeit zu vermeiden. In Produktionsbereitstellungen auf einen Pfad eines persistenten Volumes setzen
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	Nein	3	Maximale Anzahl gleichzeitiger Log-Blob-Downloads, die harness_diagnose beim Abrufen von Logs für fehlgeschlagene Schritte ausführt. Nur erhöhen, wenn die Diagnoseverzögerung hauptsächlich durch die Dauer des Log-Abrufs verursacht wird und der Pod über ausreichend Arbeitsspeicher verfügt

Semantische Suche

harness_search verwendet semantisches Routing, um Scatter-Gather-API-Aufrufe einzugrenzen, bevor sie an Harness weitergeleitet werden. Es stehen drei Suchanbieter zur Verfügung:

Anbieter	Wann verwenden
local (Standard)	Stdio-Modus für einzelne Benutzer. Führt all-MiniLM-L6-v2 über @huggingface/transformers im selben Prozess aus. Lädt das Modell bei der ersten Verwendung herunter (~23 MB); bei späteren Starts wird der Cache verwendet.
remote	HTTP-Modus für mehrere Benutzer (von Harness gehostet). Überträgt Einbettung und Abruf an einen externen Suchdienst. Die Mandantenisolierung wird über tenant_id durchgesetzt — statisches Wissen und Dokumente verwenden global, Entitätsdaten pro Konto die Konto-ID.
none	Semantische Suche vollständig deaktivieren; stattdessen wird Keyword-Scatter-Gather über alle Ressourcentypen verwendet.

Konfiguration des Remote-Anbieters:

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

Lokales Testen des Remote-Anbieters mit dem enthaltenen Stub-Dienst (keine externen Abhängigkeiten):

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

Der Stub (stub-search-service.py) implementiert denselben Vertrag für /v1/health, /v1/ingest und /v1/search wie der Suchdienst in der Produktion. Er verwendet ein einfaches Bag-of-Chars-Embedding, sodass kein Modell heruntergeladen werden muss — die Ergebnisse sind semantisch plausibel, aber nicht für den Produktionseinsatz geeignet.

HTTPS-Erzwingung

HARNESS_BASE_URL muss standardmäßig HTTPS verwenden. Wenn Sie eine URL ohne HTTPS festlegen (z. B. http://localhost:8080), verweigert der Server den Start mit folgender Meldung:

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

Audit-Protokollierung

Alle über die Registry ausgelösten Harness-API-Operationen (list, get, create, update, delete und execute) erzeugen strukturierte Audit-Ereignisse, wenn Audit-Sinks konfiguriert sind. Änderungsereignisse enthalten den Bestätigungspfad, der durch Elicitation oder automatische Genehmigung verwendet wurde, sofern ein Bestätigungskontext vorhanden ist; Leseereignisse lassen Bestätigungsmetadaten derzeit aus. Lokale Metadaten- und Schemaerkennungstools, die die Registry umgehen, wie harness_describe und harness_schema, gehören nicht zu diesem Audit-Datenstrom. Standardmäßig ist ein stderr-Sink registriert, der jedoch den normalen Logger verwendet und LOG_LEVEL befolgt; konfigurieren Sie Datei- oder Webhook-Sinks für eine dauerhafte Audit-Erfassung:

• HARNESS_AUDIT_FILE hängt JSON-Ereignisse mit Zeilenumbruch zur lokalen Erfassung an.
• HARNESS_AUDIT_WEBHOOK_URL sendet { "events": [...] }-Batches an einen HTTPS-Webhook, optional mit HARNESS_AUDIT_WEBHOOK_TOKEN. Fehlgeschlagene Batches werden mit begrenzter Kapazität erneut in die Warteschlange gestellt und schließlich mit einer Warnung verworfen, statt die Tool-Ausführung zu blockieren.
• OTEL_EXPORTER_OTLP_ENDPOINT aktiviert Audit-Spans, wenn die optionalen OpenTelemetry-Peer-Abhängigkeiten installiert sind. Der Sink verwendet einen vorhandenen Tracer-Provider, sofern einer registriert ist; andernfalls richtet er einen eigenständigen OTLP-Exporter ein.

Jedes Ereignis enthält den Toolnamen, Ressourcentyp, Vorgang, Bezeichner, Zeitstempel, Risikostufe, Ergebnis, HTTP-Methode und -Pfad, Dauer sowie gegebenenfalls die Bestätigungsmethode. Audit-Sinks dienen der Telemetrie nach bestem Bemühen; Zustellungsprobleme werden protokolliert und führen niemals dazu, dass die zugrunde liegende Harness-API-Operation wiederholt oder geändert wird. Einzelheiten zur OTel-Einrichtung und zu Span-Attributen finden Sie unter specs/005-otel-audit-sink.md.

Referenz der Tools

Der Server stellt 11 MCP-Tools bereit. Die meisten API-Tools akzeptieren org_id und project_id als optionale Überschreibungen — wenn sie nicht angegeben werden, greifen sie auf HARNESS_ORG und HARNESS_PROJECT zurück. harness_describe enthält nur lokale Metadaten und verwendet keinen Org-/Projektbereich.

URL-Unterstützung: Die meisten API-orientierten Tools akzeptieren einen Parameter url — fügen Sie eine Harness-UI-URL ein, und der Server extrahiert automatisch Org, Projekt, Ressourcentyp, Ressourcen-ID, Pipeline-ID und Ausführungs-ID. harness_describe akzeptiert url nicht.

Bereichsunterstützung: Ressourcentypen mit Konto-, Org- und Projektvarianten stellen supportedScopes in harness_describe bereit. Übergeben Sie resource_scope, wenn Sie eine bestimmte Ebene benötigen:

• resource_scope: "account" sendet nur accountIdentifier.
• resource_scope: "org" sendet accountIdentifier und orgIdentifier.
• resource_scope: "project" sendet Konto-, Org- und Projektbezeichner.

Zu den Ressourcen mit mehreren Bereichen gehören derzeit connector, service, environment, infrastructure, secret, file_store, template, policy und policy_set. Wenn resource_scope nicht angegeben ist, verwendet die Registry den Standardbereich der Ressource und die konfigurierten Standardwerte. Bei Ressourcen mit optionalem Bereich können Org/Projekt jedoch entfallen, sofern sie nicht ausdrücklich übergeben werden. Harness-URLs können den Bereich ebenfalls automatisch festlegen, wenn der Pfad Kontext auf Konto- oder Projektebene enthält.

Strukturierte Ausgabe: Jedes Tool deklariert ein MCP-outputSchema. harness_list normalisiert listenartige Harness-Antworten in objektförmige strukturierte Inhalte, damit strikte Clients sie validieren können: Arrays der obersten Ebene werden zu { "items": [...], "total": <count>, "page": <page> }, und häufige Wrapper-Schlüssel wie content, data, body, objects oder features werden bei Bedarf zu items hochgestuft. Die Textantwort enthält weiterhin die kompakte JSON-Nutzlast, die an alle Clients zurückgegeben wird.

Tool	Beschreibung
harness_describe	Verfügbare Ressourcentypen, Vorgänge und Felder ermitteln. Kein API-Aufruf — gibt lokale Registrierungsmetadaten zurück.
harness_schema	Exakte YAML-/JSON-Schema-Definitionen und Beispiele zum Erstellen/Aktualisieren von Ressourcen abrufen. Pipeline-/Vorlagenschemas sind gebündelt; Connector-, Umgebungs-, Service-, Secret- und Infrastrukturschemas sind bereichsbezogene Entitätsschemas, die aus gebündelten Snapshots oder NG /yaml-schema abgerufen werden; release_process- und release_activity-Schemas werden live von RMG /api/yamlSchema abgerufen. Unterstützt detailliertes Navigieren über path.
harness_list	Ressourcen eines bestimmten Typs mit Filtern, Suche und Paginierung auflisten.
harness_get	Eine einzelne Ressource anhand ihrer Kennung abrufen.
harness_create	Eine neue Ressource erstellen. Unterstützt Inline- und Remote-Pipelines (Git-gestützt). Fragt über elicitation eine Benutzerbestätigung ab.
harness_update	Eine vorhandene Ressource aktualisieren. Unterstützt Inline- und Remote-Pipelines (Git-gestützt). Fragt über elicitation eine Benutzerbestätigung ab.
harness_delete	Eine Ressource löschen. Fragt über elicitation eine Benutzerbestätigung ab. Destruktiv.
harness_execute	Eine Aktion für eine Ressource ausführen (Pipeline ausführen/wiederholen, Pipeline aus Git importieren, Flag umschalten, App synchronisieren). Fragt über elicitation eine Benutzerbestätigung ab. Verwenden Sie für Pipeline-Ausführungen den unten beschriebenen Workflow für Laufzeiteingaben (unterstützt die Kurzschrifterweiterung branch/tag/pr_number/commit_sha).
harness_search	Mit einer einzigen Abfrage alle Harness-Ressourcentypen durchsuchen. Verwendet semantisches Routing (lokale all-MiniLM-L6-v2-ONNX-Embeddings, 384-dim), um relevante Ressourcentypen anhand eines beim Start indizierten knowledge-Korpus vorherzusagen — dadurch wird die Suche typischerweise von ~163 Typen auf 1–8 eingegrenzt, bevor Scatter-Gather ausgeführt wird. Bei geringer semantischer Konfidenz wird auf vollständiges Keyword-Scatter-Gather zurückgegriffen. Die Antwort enthält semantic_routed und types_skipped, wenn Routing ausgelöst wird. Unter docs/search-guidelines.md erfahren Sie, wie neue Ressourcentypen auffindbar gemacht werden.
harness_diagnose	pipeline-, connector-, delegate- und gitops_application-Ressourcen diagnostizieren (Aliase: execution -> pipeline, gitops_app -> gitops_application). Für Pipelines werden Stage-/Step-Zeitangaben und Fehlerdetails zurückgegeben; für Connectors/Delegates/GitOps-Apps werden gezielte Zustands- und Fehlerbehebungssignale zurückgegeben.
harness_status	Ein Echtzeit-Dashboard zum Projektzustand abrufen — aktuelle Ausführungen, Fehlerraten und Deeplinks.

Schema-Lookup-Workflow

Verwenden Sie harness_schema vor dem Erstellen oder Aktualisieren YAML-basierter Ressourcen, damit Agents exakte Feldnamen und Einschränkungen übernehmen können, statt sie aus Fließtext abzuleiten.

• Gebündelte Schemas umfassen pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1 und agent-pipeline.
• Entitätsschemas umfassen connector, environment, service, secret und infrastructure. Sie sind bereichsbezogen (account, org oder project) und erfordern org_id/project_id, wenn der ausgewählte Bereich diese Angaben benötigt.
• Release-Management-Definitionen (release_process, release_activity) rufen das JSON-Schema live von RMG /api/yamlSchema ab (nicht gebündelt). Geben Sie beim Einschränken auf Organisation oder Projekt scope, org_id und project_id an.
• Mitgelieferte Entitäts-Snapshots werden zuerst verwendet, wenn sie zum Laufzeitkonto passen; andernfalls greift das Tool auf die Harness-NG-API /yaml-schema zurück und speichert das Ergebnis im Cache.
• Lassen Sie path für eine Zusammenfassung der Felder/Abschnitte weg und übergeben Sie anschließend einen durch Punkte getrennten path, um eine verschachtelte Definition zu untersuchen.

Beispiele:

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

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

Maintainer können die mitgelieferten Entitäts-Snapshots mit pnpm sync-entity-schemas aktualisieren, wenn sich Harness-Entitäts-YAML-Schemas ändern.

Tool-Beispiele

Verfügbare Ressourcen ermitteln:

{ "resource_type": "pipeline" }

Organisationen im Konto auflisten:

{ "resource_type": "organization" }

Projekte in einer Organisation auflisten:

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

Pipelines in einem Projekt auflisten:

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

Einen bestimmten Service abrufen:

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

Eine Pipeline ausführen:

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

Ein Feature-Flag umschalten:

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

Alle Ressourcentypen durchsuchen:

{ "query": "payment-service" }

Eine Ausführung anhand der ID diagnostizieren (Zusammenfassungsmodus — Standard):

{ "execution_id": "abc123XYZ" }

Anhand einer Harness-URL diagnostizieren:

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

Connector-Konnektivität diagnostizieren:

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

Delegate-Zustand diagnostizieren:

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

Eine GitOps-Anwendung diagnostizieren (mit Optionen):

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

Den neuesten Ausführungsbericht für eine Pipeline abrufen:

{ "pipeline_id": "my-pipeline" }

Vollständiger Diagnosemodus mit YAML und Protokollen fehlgeschlagener Schritte:

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

Zusammenfassungsmodus mit aktivierten Protokollen (das Beste aus beiden):

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

Projektzustand abrufen:

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

Datenbankschemas nach Migrationstyp gefiltert auflisten:

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

Datenbankinstanzen für ein Schema auflisten:

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

Die aufgelöste LLM-Erstellungspipeline für ein Schema und eine Instanz abrufen:

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

Snapshot-Objektnamen (z. B. Tabellen) für eine Schemainstanz auflisten:

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

Vollständige Snapshot-Metadaten für bestimmte benannte Objekte abrufen:

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

Pipeline-Ausführungsworkflow (empfohlen)

Verwenden Sie für v0-Pipelines diese Abfolge, um Fehler bei Laufzeiteingaben zu reduzieren:

1. Erforderliche Laufzeiteingaben ermitteln

• harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
• Die zurückgegebene Vorlage zeigt <+input>-Platzhalter, für die Werte benötigt werden.

2. Eingabestrategie auswählen

• Einfache Variablen: flache Schlüssel-Wert-inputs übergeben (zum Beispiel {"branch":"main","env":"prod"}).

• Komplexe/strukturelle Eingaben: input_set_ids verwenden (CI-Codebasis-/Build-Blöcke und verschachtelte Vorlageneingaben lassen sich so am besten verarbeiten).

• Kurzschlüssel für CI-Codebasis (nur Pipeline-Ausführung):

  Kurzschlüssel	Erweiterte Struktur
  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>

• Einschränkung: Die Kurzschrifterweiterung wird übersprungen, wenn inputs.build bereits vorhanden ist (explizites build hat Vorrang).

3. Ausführung starten

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

• Geben Sie bei Git-gestützten Pipelines, deren YAML aus einem nicht standardmäßigen Branch geladen werden soll, params.pipeline_branch an (wird als branch an Harness gesendet). Dieser explizite Definitionsselektor hat Vorrang vor dem Alias params.branch. inputs.branch wählt unabhängig davon den CI-Codebasis-Branch aus:

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

4. Optional: beides kombinieren

• Verwenden Sie input_set_ids für die Grundstruktur und inputs für einfache Überschreibungen.

Für v1-Pipelines:

1. harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>") abrufen. Geben Sie bei Git-gestützten Pipelines branch_name, connector_ref und repo_name über params an.
2. Verwenden Sie jedes zurückgegebene inputs[].details.name als Schlüssel der obersten Ebene in harness_execute.inputs.
3. harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}) ausführen. Der Server umschließt diese Werte mit einer YAML-Wurzel inputs: und sendet den inputs_yaml-Body der API.

Wenn erforderliche Felder nicht aufgelöst werden können, gibt das Tool einen Vorabfehler mit den erwarteten Schlüsseln und vorgeschlagenen Eingabemengen zurück. Verfügbare Kurzzuordnungen können Sie mit harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands) anzeigen.

Dynamische Pipeline-Ausführung

Verwenden Sie pipeline_dynamic_execution.run, wenn ein Agent oder ein externes System zur Laufzeit das vollständige v0-Pipeline-YAML generiert und es mit einer vorhandenen Harness-Pipeline-Shell ausführen muss. Dies ist kein Ersatz für das normale pipeline.run: Die gespeicherte v0-Pipeline muss bereits vorhanden sein, Allow Dynamic Execution muss sowohl auf Konto- als auch auf Pipelineebene aktiviert sein, und der Aufrufer benötigt die Berechtigungen Edit und Execute für die Pipeline.

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

Einschränkungen:

• body muss ein Objekt mit einem Feld yaml sein. Rohe Zeichenfolgen als Body werden vom öffentlichen Schema harness_execute abgelehnt.
• body.yaml kann eine YAML-Zeichenfolge oder ein JSON-Pipelineobjekt sein; JSON wird vor der Anfrage in YAML serialisiert.
• Platzhalter für Laufzeit-<+input> werden von dieser API nicht aufgelöst. Senden Sie vollständig aufgelöstes YAML.
• Eingabemengen, selektive Stufenausführung, Wiederholungsversuche und Trigger werden vom Endpunkt für die dynamische Ausführung nicht unterstützt.
• Die Aktion ist high_write und verwendet den normalen Bestätigungs-/Auto-Genehmigungspfad. Die Antwort projiziert den API-Umschlag auf { "execution_id": "...", "status": "..." } und enthält einen Ausführungslink openInHarness, sofern Bereichsdaten verfügbar sind.

Wenn Harness die Ausführung mit dem Hinweis ablehnt, dass sie nicht aktiviert ist, überprüfen Sie sowohl die kontoweite Einstellung Allow Dynamic Execution als auch den Schalter auf Pipelineebene unter Pipeline -> Advanced Options -> Dynamic Execution Settings.

Forensische Analyse von Ausführungseingaben

Verwenden Sie execution_inputs nach einer Ausführung, um das zusammengeführte Eingabe-YAML zu untersuchen, das eine bestimmte Ausführung erzeugt hat. Dies ist hilfreich, wenn ein Fehler von der Zusammenführung von Eingabemengen, Git-gestützten Branches von Eingabemengen oder Trigger-/Laufzeitwerten abhängt, die sich allein anhand der Ausführungsseite nur schwer rekonstruieren lassen.

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

Die get-Antwort wird wie folgt projiziert:

• executionId – die Plan-Ausführungs-ID aus resource_id.
• inputSetYaml – das zusammengeführte Laufzeit-Eingabe-YAML für die Ausführung oder null.
• inputSetTemplateYaml – die Eingabevorlage zum Ausführungszeitpunkt oder null.
• resolvedYaml – YAML mit aufgelösten Ausdrücken, wenn resolve_expressions=true, andernfalls üblicherweise null.
• inputSetDetails – beitragende gespeicherte Eingabemengen als { identifier, name }-Paare.
• inputSetBranchName – Quellbranch für Git-gestützte Eingabemengen oder null.

execution_inputs ist nur für get verfügbar und birgt ein Leserisiko. Wenn resolve_expressions weggelassen wird, lässt der Server die API-Abfrageparameter weg und Harness verwendet den standardmäßigen Auflösungsmodus UNKNOWN.

Pipeline-Ausführung im Wartemodus

Übergeben Sie für pipeline.run, pipeline.retry und pipeline_v1.run wait: true, damit der Server so lange abfragt, bis die Ausführung einen Endstatus erreicht. So lassen sich Pipeline-Start und Statusprüfung in einem Toolaufruf erledigen, statt den Client oder das LLM eine Abfrageschleife ausführen zu lassen.

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

Verhalten des Wartemodus:

• Das Standard-Timeout beträgt 600 Sekunden; der zulässige Bereich liegt zwischen 10 und 7200 Sekunden.
• Das anfängliche Abfrageintervall beträgt standardmäßig 3 Sekunden, erhöht sich jeweils um den Faktor 1,5 und ist auf 30 Sekunden begrenzt.
• Bei Erfolg oder Fehler enthält die Antwort Felder wie execution_id, execution_status, execution_terminal, execution_elapsed_ms und execution_poll_count.
• Wenn das Timeout ausgelöst wird, war der ursprüngliche Trigger dennoch erfolgreich; die Antwort enthält execution_timed_out: true und _wait.hint mit dem zuletzt beobachteten Status.
• Wenn die Abfrage nach erfolgreichem Trigger fehlschlägt, enthält die Antwort _wait.error und einen Hinweis zur erneuten Prüfung. Führen Sie die Pipeline nicht blind erneut aus, bevor Sie bestätigt haben, dass die erste Ausführung nicht läuft.
• Zu den fehlgeschlagenen Endstatus gehört _diagnose_hint, das auf harness_diagnose(resource_type="execution", options={execution_id: "..."}) verweist.

Den AI DevOps Agent bitten, eine Pipeline zu erstellen:

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

Einen Service per natürlicher Sprache aktualisieren:

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

Pipeline-Speichermodi

Harness-Pipelines können auf drei Arten gespeichert werden:

Modus	Beschreibung	Wann verwenden
Inline	Pipeline-YAML wird in Harness gespeichert	Standard. Einfachste Einrichtung, kein Git erforderlich.
Remote (External Git)	Pipeline-YAML wird in GitHub, GitLab, Bitbucket usw. gespeichert.	Teams, die Pipeline-as-Code mit Git und einem externen Anbieter verwenden.
Remote (Harness Code)	Pipeline-YAML wird in einem Harness-Code-Repository gespeichert	Teams, die das integrierte Git-Hosting von Harness verwenden.

Eine Inline-Pipeline erstellen (Standard):

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

Eine Remote-Pipeline erstellen (External Git – z. B. 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"
  }
}

Eine Remote-Pipeline erstellen (Harness Code – kein Connector erforderlich):

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

Eine Remote-Pipeline aktualisieren:

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

Eine Pipeline aus einem externen Git-Repository importieren:

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

Eine Pipeline aus einem Harness-Code-Repository importieren:

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

Einen Connector erstellen:

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

Einen Trigger löschen:

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

Eingabemengen für eine Pipeline auflisten:

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

Eine bestimmte Eingabemenge abrufen:

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

Eine Eingabemenge erstellen:

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

Eine Eingabemenge aktualisieren:

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

Eine Eingabemenge löschen:

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

Ressourcentypen

274 Ressourcentypen, organisiert in 44 Toolsets. Jeder Ressourcentyp unterstützt eine Teilmenge der CRUD-Operationen und optionale Ausführungsaktionen.

Plattform

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
organization	x	x	x	x	x
project	x	x	x	x	x

Pipelines

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
pipeline	x	x	x	x	x	run, retry
pipeline_v1 (Alpha)	x	x	x	x	x	run
pipeline_dynamic_execution						run
execution	x	x				interrupt
execution_inputs		x
trigger	x	x	x	x	x
pipeline_summary		x
input_set	x	x	x	x	x
runtime_input_template		x
runtime_input_template_v1		x
pipeline_resolved_yaml		x
approval_instance	x					approve, reject

Beide Pipeline-YAML-Ressourcentypen sind verfügbar, wenn das Pipelines-Toolset aktiviert ist. HARNESS_PIPELINE_VERSION und der HTTP-Initialisierungsheader x-harness-pipeline-version legen die Standard-Versionspräferenz fest; sie blenden die andere Version nicht aus.

KI-Agenten

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
agent	x	x	x	x	x
agent_run	x

Services

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
service	x	x	x	x	x

Umgebungen

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
environment	x	x	x	x	x	move_configs

Connectoren

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
connector	x	x	x	x	x	test_connection
connector_catalogue	x
llm_model	x

Infrastruktur

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
infrastructure	x	x	x	x	x	move_configs

Secrets

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
secret	x	x

Ausführungsprotokolle

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
execution_log		x

Audit-Trail

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
audit_event	x	x

Delegates

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
delegate	x	x
delegate_token	x	x	x		x	revoke, get_delegates

Code-Repositories

Ressourcentyp	List	Get	Create	Update	Delete	Execute Actions
repository	x	x	x	x
branch	x	x	x		x
commit	x	x	x			diff, diff_stats
file_content	x	x				blame
tag	x		x		x
repo_rule	x	x
space_rule	x	x

Die Erstellung von commit überträgt eine oder mehrere Dateiaktionen direkt über die Harness-Code-API, ohne das Repository zu klonen. Übergeben Sie body.title, body.branch und body.actions; jede Aktion ist CREATE, UPDATE, DELETE oder MOVE, und für UPDATE ist die aktuelle Blob-SHA erforderlich.

file_content list gibt alle Pfade an einer Referenz zurück; get gibt Datei- oder Verzeichnisinhalte zurück (lassen Sie path weg oder übergeben Sie einen leeren Wert, um das Stammverzeichnis des Repositorys abzurufen; verschachtelte Pfade behalten ihre Schrägstriche bei). Lassen Sie git_ref weg, um den Standardbranch des Repositorys zu verwenden – raten Sie nicht bei main.

Artefaktregistrierungen

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
registry	x	x
artifact	x
artifact_version	x
artifact_file	x

Dateispeicher

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
file_store	x	x	x	x	x	list_children

file_store verwaltet Harness File Store-Dateien und -Ordner über die generischen Tools. Unterstützt werden Account-, Org- und Projektbereiche. Übergeben Sie resource_scope="account"|"org"|"project" oder fügen Sie eine Harness File Store-URL ein, damit der Server Bereich und IDs ableiten kann.

Häufige Aufrufe:

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

Einschränkungen für Multipart-Bodies:

• Erstellen/Aktualisieren akzeptiert JSON body, das anschließend für /ng/api/file-store in multipart/form-data umgewandelt wird.
• name, type (FILE oder FOLDER) und parent_identifier sind erforderlich. Verwenden Sie das Literal "Root" nur für das Stammverzeichnis des ausgewählten Bereichs.
• Beim Erstellen von FILE ist genau eines von content (UTF-8-Zeichenfolge) oder content_base64 (gültiges, nicht leeres Base64) erforderlich. Beim Aktualisieren von FILE kann der Inhalt bei reinen Metadatenaktualisierungen weggelassen werden; alternativ kann genau ein Inhaltsfeld angegeben werden, um den Inhalt zu ersetzen.
• Beim Erstellen/Aktualisieren von FOLDER müssen content und content_base64 weggelassen werden.
• Optionales file_usage muss MANIFEST_FILE, CONFIG oder SCRIPT sein. Optionale skalare Metadaten wie description, mime_type, path und tags müssen Zeichenfolgen sein.
• Die Größe hochgeladener Inhalte ist auf 100 MB begrenzt. Bestätigungsaufforderungen schwärzen vor der Abfrage Vorschauen von content, content_base64 und contentBase64.

list_children akzeptiert entweder eine Kurzform (resource_id plus params.folder_name oder params.file_store_id/params.folder_identifier plus params.folder_name) oder ein vollständiges FileStoreNode-body mit identifier, name und type: "FOLDER". Vollständige Bodies verwenden Harness camelCase parentIdentifier; in der Kurzform kann params.parent_identifier verwendet werden.

Vorlagen

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
template	x	x	x	x	x

Vorlagenoperationen verwenden die Harness Template-Servicepfade (/template/api/templates...). Zum Erstellen und Aktualisieren ist die vollständige YAML-Zeichenfolge der Vorlage in body.template_yaml oder body.yaml erforderlich. version_label zielt beim Aktualisieren/Löschen auf eine bestimmte Version ab; beim Löschen ohne version_label werden alle Versionen gelöscht.

Dashboards

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
dashboard	x	x
dashboard_data		x

Datenbank-DevOps

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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-Ressourcen sind standardmäßig aktiviert und größtenteils auf Projektebene angesiedelt. Beginnen Sie mit iacm_workspace, um Workspace-Kennungen zu finden, und verwenden Sie dann dieses workspace_id für Workspace-Ressourcen, Kosten und Aktivitätsunterschiede. Verwenden Sie iacm_variable_set für wiederverwendbare Variablensätze auf Account-, Org- oder Projektebene. Die Provider-Registry ist auf Account-Ebene angesiedelt.

iacm_module umfasst Account-, Org- und Projektbereiche. Standardmäßig wird die Account-Registry verwendet. Jeder Vorgang (Auflisten, Abrufen, Erstellen, Aktualisieren) sendet dieselben Abfrageparameter scope_org / scope_project, sodass ein von Ihnen erstelltes Modul im Bereich auffindbar ist, in dem es erstellt wurde. Wählen Sie den Bereich mit resource_scope="account" | "org" | "project" plus org_id/project_id aus. Die Bereichsangabe ist optional: Wenn resource_scope weggelassen wird, gelten org_id/project_id nur, wenn Sie sie explizit übergeben — konfigurierte Standardwerte für HARNESS_ORG/HARNESS_PROJECT werden nicht angewendet. Eine aktive Projektkonfiguration kann daher nicht unbemerkt ein Account-Modul unter einem Projekt registrieren. Die Felder org/project im Modul-Body geben den Git-Connector an und stehen in keinem Zusammenhang mit diesem Sichtbarkeitsbereich.

Erstellen/Aktualisieren von iacm_workspace gibt nur { policy_evaluation } zurück — rufen Sie anschließend harness_get auf, um den Workspace abzurufen. Erstellen/Aktualisieren von iacm_variable_set und iacm_module gibt die Ressource selbst zurück. Erstellen von iacm_provider gibt nur { id } zurück — rufen Sie anschließend harness_get auf. Aktualisierungen sind ausschließlich versionsbezogen (POST/PUT /providers/{id}/version) — es gibt kein Metadaten-PUT. Versionsschreibvorgänge können einen leeren Body zurückgeben; HarnessClient normalisiert diesen zu { status: "SUCCESS", message: "No content" }.

Die Aktualisierung von Variablensätzen erfolgt per HTTP PUT mit vollständig ersetzten Sammlungen — rufen Sie immer zuerst harness_get auf und senden Sie dann den vollständigen gewünschten Body per PUT (terraform_variables / environment_variables sind bei Aktualisierungen erforderlich; durch Weglassen/leere Werte werden Connectoren und Variablendateien gelöscht). Auch die Modulaktualisierung erfolgt per PUT — bei optionalen Feldern empfiehlt sich erst das Abrufen und dann das PUT. Schreibvorgänge sind medium_write und erfordern eine Bestätigung (Abfrage oder confirm: true).

RBAC für Variablensätze und Provider-Registry (iac_variableset_*, iac_providerregistry_*) ist in Harness derzeit experimentell — Zugriffsprüfungen lassen den Zugriff immer zu, bis iac-server die Durchsetzung aktiviert. RBAC für die Modul-Registry (iac_registry_view / iac_registry_edit) ist aktiv und kann durchgesetzt werden. MCP leitet das PAT/SAT des Aufrufers unverändert weiter.

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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

Typischer Workflow:

1. harness_list(resource_type="iacm_workspace", org_id="...", project_id="..."), um den Workspace zu finden.
2. harness_create / harness_update für iacm_workspace, um einen Workspace von Grund auf oder anhand einer Vorlage (associated_template) zu erstellen oder einen vorhandenen Workspace zu aktualisieren — die Antwort enthält nur { policy_evaluation }.
3. harness_get(resource_type="iacm_workspace", workspace_id="..."), um den erstellten/aktualisierten Workspace abzurufen.
4. harness_list / harness_create / harness_update für iacm_variable_set (optional mit resource_scope) für wiederverwendbare Terraform-/Env-Variablensätze — die Antwort ist die VariableSet-Ressource.
5. harness_list / harness_create / harness_update für iacm_module für die Modul-Registry (name + system erforderlich; fügen Sie resource_scope mit org_id/project_id für ein Modul auf Org- oder Projektebene hinzu) — die Antwort ist die Modulressource.
6. harness_list / harness_create / harness_update für iacm_provider für die Provider-Registry des Accounts (body.type ist beim Erstellen erforderlich; beim Erstellen wird nur { id } zurückgegeben — rufen Sie anschließend harness_get auf; Aktualisierungen erstellen/aktualisieren nur Versionen) — eine Versionsaktualisierung kann einen leeren Erfolgs-Body zurückgeben.
7. harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="..."), um Terraform-Ressourcen, Ausgaben und Datenquellen zu prüfen.
8. harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="..."), um Kosteneinträge pro Ausführung zu überprüfen.
9. harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="..."), um Ressourcenunterschiede vor und nach einer Plan-, Apply- oder Destroy-Aktivität zu prüfen.

IaCM-Listenantworten geben page_count als Anzahl nur für die aktuelle Seite zurück (außer bei iacm_variable_set, das nicht paginiert ist). Wenn has_more den Wert true hat, fordern Sie weiterhin die nächste, bei 1 beginnende Seite an und summieren Sie die Seitenanzahlen, falls Sie eine Gesamtzahl benötigen.

Internes Entwicklerportal (IDP)

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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

Verwenden Sie harness_execute(resource_type="pull_request", action="close", ...) für einen expliziten Schließvorgang. harness_update akzeptiert außerdem body.state (open oder closed) und leitet Zustandsänderungen an den dedizierten Harness Code-PR-Zustandsendpunkt weiter. Titel-/Beschreibungsänderungen müssen in einem separaten Aktualisierungsaufruf gesendet werden.

Verwenden Sie harness_list(resource_type="pr_activity", filters={type: ["comment", "code-comment"]}, ...), um PR-Kommentare zu lesen. Verwenden Sie pr_comment für Schreibvorgänge an Kommentaren.

Verwenden Sie harness_execute(resource_type="pr_comment", action="resolve", ...), um einen Kommentar-Thread aufzulösen, und action="unresolve", um ihn wieder zu öffnen. Für keines der beiden ist ein Body erforderlich. comment_id muss der Wert id einer Zeile aus pr_activity sein, bei der parent_id dieser Zeile null ist. Die API weist IDs von Antworten zurück.

Release Management

Release-Management-(RMG-)Ressourcen sind standardmäßig aktiviert. Definitionsressourcen (release_process, release_activity) unterstützen Auflisten/Abrufen/Erstellen/Aktualisieren/Löschen mit body.yaml; rufen Sie vor dem Erstellen/Aktualisieren harness_schema(resource_type="release_process"|"release_activity") auf. Ausführungsressourcen überwachen laufende Releases — für die meisten Auflistungsvorgänge ist release_id erforderlich (UUID aus harness_list resource_type=release oder der URL-Slug der Benutzeroberfläche, z. B. identifier-1.0.0-abc). Fügen Sie eine RMG-Release-URL in harness_list ein, um release_id automatisch auszufüllen.

RMG-Aufrufe verwenden ${HARNESS_BASE_URL}/gateway/rmg mit Account-Bereichsangabe über den Header Harness-Account. Für Org-/Projektbereiche wird die Bereichsangabe über Header vorgenommen, wenn org_id/project_id angegeben sind. release_execution_phase ist nur zum Auflisten vorgesehen — verwenden Sie das Feld identifier jedes Phasenelements als params.phase_identifier, wenn Sie harness_get für Phaseneingabe-/Phasenausgaberessourcen aufrufen (rufen Sie harness_get nicht für release_execution_phase selbst auf). Die Filterung von Release-Listen nach status erfolgt clientseitig und nur für die aktuelle Seite. Rufen Sie bei Ergebnissen über mehrere Seiten hinweg weitere Seiten mit denselben Filtern ab.

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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

Typischer Workflow:

1. harness_list(resource_type="release_process", org_id="...", project_id="..."), um Orchestrierungsprozessdefinitionen zu ermitteln.
2. harness_schema(resource_type="release_process") (oder release_activity) vor dem Erstellen/Aktualisieren; anschließend harness_create / harness_update mit body.yaml.
3. harness_list(resource_type="release", org_id="...", project_id="..."), um aktive oder kürzlich erfolgte Releases zu finden (standardmäßig Rückblick auf 30 Tage; optional filters.status, filters.search_term, filters.days_back).
4. harness_get(resource_type="release", release_id="...") für Release-Details.
5. harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) für den Phasenstatus; dasselbe release_id für release_execution_task und release_execution_activity.
6. harness_get für release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_output oder release_execution_activity_input mit release_id sowie params.phase_identifier / params.activity_identifier / activity_execution_id, wie für jede Ressource dokumentiert.

Einheitliche Suche

Das optionale Toolset unified-search (HARNESS_TOOLSETS=+unified-search) ergänzt eine semantische (bedeutungsbasierte) Suche über alle Quellen, die search-service bereitstellt. Die Ergebnisse sind auf das Konto des Aufrufers beschränkt und werden nach RBAC gefiltert. Für das Konto muss das Feature-Flag für die semantische Suche aktiviert sein.

Ressourcentyp	Auflisten	Abrufen	Aktionen ausführen
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") listet die Quellen auf. Die Filtersyntax finden Sie unter harness_describe(resource_type="unified_search").

Dies ist von den Anbietern für semantisches Routing in Semantische Suche getrennt, die MCP-Ressourcendefinitionen und Dokumente indizieren, um die Anzahl der Aufrufe von harness_search einzugrenzen.

Vibe

Das standardmäßig aktivierte Toolset vibe deckt den Vibe Orchestrator-BFF-Vertrag unter ${HARNESS_BASE_URL}/vibe/v1 ab. Es verwendet die vorhandene Harness-Verbindung und den Konto-Header, ohne Konto-/Org-/Projekt-Abfrageparameter oder Scope-Felder zu Request-Bodys hinzuzufügen. Das Team hat den Vibe-Ablauf mit Harness-API-Key-Authentifizierung (PAT/SAT) validiert; daher ist für Standardsitzungen keine Opt-in-Einstellung erforderlich. Die kuratierten OpenAPI-Dokumente beschreiben Bearer-/Sitzungsauthentifizierung; der OAuth-Modus des Servers leitet das Bearer-Token der aktuellen Sitzung weiter. Automatisierte Regressionstests überprüfen beide Header-Pfade; die Gateway-Authentifizierung hängt weiterhin von der Konfiguration der Zielumgebung ab.

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
vibe_project			x			prepare, deploy
vibe_app_lifecycle		x				events

Die API unterstützt zwei Wege zur Datenübermittlung. Behalten Sie diese API-nativen Request-Formate bei:

Für den Coding-Agent verfügbare Quelle	API-Ablauf
GitHub-Repository-Link/Connector	harness_create mit resource_type="vibe_project" und body.mode sowie den modusspezifischen Feldern. Der Vertrag nennt github_link und github_connector, definiert jedoch nicht deren URL-, Branch- oder Connector-Feldformate; diese Felder werden an das Backend weitergeleitet, ohne eine Zuordnung zu erfinden.
ZIP-Datei	Rufen Sie prepare mit dem App-Namen und den Dateimetadaten auf, laden Sie die Bytes zum zurückgegebenen signierten Ziel hoch und rufen Sie anschließend deploy auf.
Lokales Quellverzeichnis	Der Coding-Agent archiviert den vorgesehenen Workspace-Quellcode lokal als ZIP und folgt dann dem ZIP-Ablauf. Ein lokaler Pfad oder Gesprächskontext ist keine von der API unterstützte Quelle für Uploads.

Wenn Sie ein Verzeichnis verpacken, schließen Sie den Quellcode, Manifeste, Lockfiles, Konfiguration und vorgesehene nicht committete Änderungen ein, die zum Erstellen benötigt werden. Schließen Sie Zugangsdaten, .git, installierte Abhängigkeiten und generierte Artefakte aus. Das Verpacken und der signierte Upload erfolgen dort, wo die Dateien zugänglich sind; ein gehosteter MCP-Server kann nicht auf das lokale Verzeichnis des Coding-Agenten zugreifen.

Bereiten Sie für eine vorhandene ZIP-Datei den Upload vor:

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

Übergeben Sie dies an harness_execute. Die Größe muss der tatsächlichen ZIP-Datei entsprechen; size_bytes, content_type und md5 sind optional und dürfen null sein. Zusätzliche Vorbereitungsfelder bleiben für die Backend-Validierung erhalten, soweit dies von der OpenAPI zugelassen wird. Die Vorbereitung gibt projectId, sourceId und upload zurück, einschließlich uploadUrl, method, headers und expiresAt für jede Datei. Laden Sie die Dateibytes direkt mit der angegebenen signierten URL, Methode und den Headern hoch; übernehmen Sie die URL exakt und fügen Sie der Speicheranforderung keine Harness-Zugangsdaten hinzu. Die Vorbereitungsaktion liest keine lokalen Dateien und lädt sie auch nicht hoch.

Führen Sie nach einem erfolgreichen Upload die Bereitstellung ausdrücklich aus:

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

Verwenden Sie für JSON-Importe stattdessen das zurückgegebene id. Die Bereitstellung akzeptiert außerdem body: {"project_id": "<Vibe app id>"} oder params.app_id; das API-Drahtfeld lautet snake_case project_id, obwohl die Vorbereitung camelCase projectId zurückgibt. Das oberste project_id des generischen Tools ist eine Harness-Scope-Kennung und wird niemals als Vibe-App-ID verwendet. Import und Vorbereitung erstellen die App/Quelle; keiner der beiden Vorgänge startet eine Bereitstellung. Schreibvorgänge werden nicht automatisch wiederholt, und für die Bereitstellung gilt die bestehende Bestätigungsrichtlinie für Aktionen mit hohem Risiko.

Lesen Sie den Fortschritt mit harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>"). Dabei bleiben App-URLs, Ausführungsphasen, Teilschritte, Fehler, Protokollzeilen und Details des Build-Analyzers erhalten. Die Ausführungsaktion events akzeptiert resource_id oder params.app_id und verarbeitet den SSE-Endpunkt als begrenzten Batch: bis zu 20 JSON-Ereignisse oder fünf Sekunden nach dem Verbindungsaufbau, mit einer Antwortbegrenzung von 1 MiB. Diese Grenzwerte gelten für den Vibe-Endpunkt. Das HARNESS_API_TIMEOUT_MS der Verbindung begrenzt außerdem gemeinsam die Verbindungs- und Stream-Verarbeitung; bei Ablauf wird ein Timeout-Fehler zurückgegeben. Ein abgeschlossener Batch gibt events und stop_reason (end, event_limit oder duration_limit) zurück und schließt den Stream. Weder anfängliche Verbindungsfehler noch unterbrochene Streams werden erneut versucht. Ereignisse sind flüchtige Diffs ohne dokumentierten Replay-Cursor; verwenden Sie für eine maßgebliche Momentaufnahme den Lifecycle-Abruf. Beide Lifecycle-Lesevorgänge sind im schreibgeschützten Modus verfügbar.

Feature-Flags

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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-Ressourcen (Split.io) — fme_*-Ressourcen unterstützen Dual-Mode-Scoping: Bei älteren Aufrufen wird workspace_id übergeben und die Split.io-API (api.split.io) angesprochen; bei neueren Aufrufen werden org_id+project_id gemeinsam übergeben und stattdessen Harness-native Endpunkte verwendet (standardmäßige HARNESS_API_KEY/HARNESS_BASE_URL, dieselbe Authentifizierung wie bei allen anderen harness_*-Ressourcen). Die gleichzeitige Übergabe von workspace_id und org_id/project_id im selben Aufruf oder die Kombination von org_id mit ausschließlich project_id ist ein Fehler — wählen Sie pro Aufruf einen Modus. Alle nachfolgend aufgeführten Vorgänge sind im älteren Modus unverändert verfügbar, sofern die Ressource nicht ausdrücklich als ausschließlich Harness-nativ gekennzeichnet ist. Die Abdeckung im Harness-nativen Modus ist derzeit eingeschränkter:

• fme_workspace — kein natives Harness-Äquivalent; nur Legacy (wird verwendet, um workspace_id-Werte zu ermitteln).

• fme_environment — list mit zwei Modi (workspace_id oder org_id+project_id). get/create/update/delete sind nur nativ in Harness (/fme/api/v4/environments) — MCP hatte für diese Vorgänge nie einen workspace_id-Vertrag. Die native Liste verwendet optionale offset/limit (max. 100; harness_list size wird limit zugeordnet); der Umschlag {data, limit, offset, totalCount} wird zu items/total hochgestuft. Native Create-/Update-Vorgänge verwenden isProduction (production wird als Alias akzeptiert). Native Updates verwenden JSON Merge Patch; name und isProduction können nicht geleert werden. Der Name darf maximal 15 Zeichen lang sein.

• fme_feature_flag — zwei Modi, beide Zweige vollständig angebunden. Nativ in Harness (org_id+project_id): list/get/create/delete rufen /fme/api/v4/feature-flags auf (Body für create: name, trafficType, optional description/tags/owners, gemäß CreateFeatureFlagRequest); update sendet einen Merge-Patch an /fme/api/v4/feature-flags/{name}; archive/unarchive rufen /fme/api/v4/feature-flags/{name}/archive|unarchive auf (nur optional comment — kein title, gemäß ArchiveUnarchiveRequest); kill/restore/reallocate rufen /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate mit environment_id als Query-Parameter auf (optional comment/title, gemäß FeatureFlagDefinitionActionRequest).

• fme_feature_flag_definition — get/create/update unterstützen weiterhin beide Modi (workspace_id oder org_id+project_id). list/delete/kill/restore/reallocate sind nur nativ in Harness (org_id+project_id) — MCP hatte für diese Vorgänge nie einen workspace_id-Vertrag. Die native Liste erfordert feature_flag_name und verwendet offset/limit (Standardwert 100, max. 100); sie akzeptiert kein environment_id. Delete und Execute erfordern environment_id. Kill/Restore/Reallocate sind dieselben Aktionen wie bei fme_feature_flag. Der Body für Get/Create/Update entspricht dem Legacy-Format (treatments, defaultTreatment, defaultRule, optional rules/baselineTreatment/trafficAllocation/comment), zuzüglich optionalem title im nativen Harness-Modus. Native Updates verwenden JSON Merge Patch.

• fme_rollout_status — list mit zwei Modi. Übergib org_id+project_id (bevorzugt) oder das veraltete workspace_id. Die native Paginierung verwendet offset/limit (max. 100; harness_list size wird limit zugeordnet); die Ergebnisse werden zu items/total hochgestuft. Jedes Element enthält id, name und optional description.

• fme_rule_based_segment — (Veraltet — siehe fme_segment.) Der native Harness-Modus wird bei jedem Vorgang abgelehnt (list/get/create/delete) — verwende stattdessen fme_segment; diese Ressource unterstützt nur den Legacy-workspace_id-Vertrag.

• fme_rule_based_segment_definition — (Veraltet — siehe fme_segment_definition.) Der native Harness-Modus wird bei jedem Vorgang/jeder Aktion abgelehnt (list/update/enable/disable/change_request) — verwende stattdessen fme_segment_definition (dort gibt es kein entsprechendes enable/disable/change_request); diese Ressource unterstützt nur den Legacy-workspace_id/environment_id-Vertrag.

• fme_traffic_type — list mit zwei Modi. Übergib org_id+project_id (bevorzugt) oder das veraltete workspace_id. Die native Paginierung verwendet offset/limit (max. 100; harness_list size wird limit zugeordnet); die Ergebnisse werden zu items/total hochgestuft. Jedes Element enthält id und name (kein displayAttributeId).

• fme_identity — create/update sind noch nicht implementiert, wenn org_id+project_id gemeinsam übergeben werden; andernfalls wird der Vorgang als normaler Legacy-Aufruf ausgeführt.

• fme_standard_segment — veraltet. Der Legacy-workspace_id ruft weiterhin Split v2 auf. Der native Harness-Modus wird abgelehnt — verwende fme_segment.

• fme_segment_keys — list/update bleiben Legacy (workspace_id / environment_id+segment_name). Der native Harness-Modus (org_id+project_id) wird abgelehnt — verwende fme_segment_definition execute list_keys/add_keys/remove_keys.

• fme_segment — nur nativ (org_id+project_id). CRUD. list/get/update/delete erfordern segment_type: STANDARD | LARGE | RULE_BASED. Create-Body: name, trafficType, segmentType; optional description, tags, owners.

• fme_segment_definition — nur nativ. CRUD sowie Execute list_keys/add_keys/remove_keys. Update betrifft nur die Beschreibung. Delete schlägt mit hasDependents fehl, solange Schlüssel vorhanden sind.

• fme_metric — nur nativ in Harness (keine Unterstützung für Legacy-workspace_id). list/get/create/update/delete sind mit /fme/api/v4/metrics verbunden (lists harness_list size wird limit zugeordnet). create erfordert spread, obwohl das Backend-CreateMetricRequest es optional lässt (Standardwert PER) — ein strengerer Vertrag nur auf MCP-Seite, da das Weglassen die Semantik einer RATE-Metrik unbemerkt ändert. update ist JSON Merge Patch; name/trafficType sind unveränderlich und werden nicht akzeptiert. delete ist ein dauerhaftes Hard Delete (kein Archivieren/Wiederherstellen) — als destructive klassifiziert.

• fme_event_type — nur nativ in Harness (keine Unterstützung für Legacy-workspace_id). Schreibgeschützt: list/get sind mit /fme/api/v4/event-types verbunden; id ist der Ereignisname. Sichtbar sind nur Ereignistypen mit Ereignissen aus den letzten 30 Tagen; get gibt für einen Ereignistyp außerhalb des Traffic-Type-Bereichs des anfragenden Workspace oder bei mehr als 30 Tagen Inaktivität einen 404-Fehler zurück. Listenfilter: name (Teilzeichenfolge), traffic_type (nach ID oder Name), offset/limit (harness_list size wird limit zugeordnet). Verwende dies, um echte Ereignistyp-IDs zu ermitteln, bevor du in fme_metrics baseEventTypes/filterEventType oder event_type_ids-Filter auf eine ID verweist, statt eine ID zu erraten.

• fme_experiment — nur nativ in Harness (keine Unterstützung für Legacy-workspace_id). CRUD ist mit /fme/api/v4/experiments verbunden. list erfordert parent_type (FEATURE_FLAG, AI_CONFIG; CONFIG gibt 404 zurück) und verwendet standardmäßig ACTIVE-Experimente, sofern status nicht übergeben wird. create erfordert environment_id (Query-Parameter) sowie parent/name/startAt/endAt/baselineTreatment/comparisonTreatments im Body; das übergeordnete Element muss in dieser Umgebung vorhanden sein. update ist JSON Merge Patch; parent und environment können nicht geändert werden. delete ist ein dauerhaftes Hard Delete — als destructive klassifiziert. Optionales owners bei Create/Update: Jeder Eintrag ist {type: "USER", id or email} oder {type: "GROUP", identifier}. Optionales rule (Label, auf das die Ergebnisse der Targeting-Regel beschränkt sind; bei Create standardmäßig "default", wenn es weggelassen wird; bei Update wird es durch null geleert) und tags ([{name}]; bei Update wird die Liste ersetzt, null/[] leert sie) bei Create/Update. list akzeptiert einen tags-Arrayfilter (Experimente mit einem beliebigen der Tag-Namen); Elemente enthalten tags und rule.

• fme_experiment_settings — Statistische Einstellungen und Überwachungseinstellungen für ein einzelnes Experiment (Testtyp, Signifikanzschwelle, Korrektur für Mehrfachvergleiche, Mindeststichprobengröße, Überprüfungszeitraum, Varianzreduktion). Nur get/update/delete — 1:1-Zuordnung zum Experiment, kein list. get gibt immer die angewendeten Einstellungen zurück (eigene Überschreibung oder Organisationsstandards) und liefert nur dann 404, wenn das Experiment selbst nicht existiert. update ist JSON Merge Patch und erstellt implizit die Überschreibung auf Experimentebene. delete setzt auf die Organisationsstandards zurück (idempotent) — als destructive klassifiziert, obwohl der Vorgang nicht dauerhaft ist.

• fme_experiment_alerting — Gibt an, ob ein einzelnes Experiment Benachrichtigungen zu Signifikanzrückgängen abonniert hat. Nur get/update. get gibt {id, isEnabled} zurück und meldet isEnabled: false, wenn keine Benachrichtigungsrichtlinie vorhanden ist; ein 404-Fehler tritt nur auf, wenn das Experiment selbst nicht existiert. update ist JSON Merge Patch mit einem erforderlichen booleschen Wert isEnabled.

• fme_experiment_result — Ausgewertete Ergebnisse pro Metrik für den letzten Berechnungslauf eines Experiments. Nur list (kein get — Ergebnisse haben keine eigene Kennung). Eine Zeile pro Paar aus Metrik und Vergleichsbehandlung über alle Metrikkategorien hinweg. Optionale Filter: metric_ids, comparisons. Bezieht sich nur auf den letzten Lauf — kein Zugriff auf historische Daten.

Im Einzelbenutzer-/Self-Hosted-Modus verwendet die Authentifizierung im Legacy-Modus ein Bearer-Token aus HARNESS_FME_API_KEY und greift andernfalls auf ein Nicht-Platzhalter-HARNESS_API_KEY zurück. HARNESS_FME_API_KEY kann ein Split-Admin-Schlüssel oder ein FME-berechtigtes Harness-PAT/SAT sein, wird im multi-user-Modus jedoch abgelehnt, damit gemeinsam genutzte Bereitstellungen nicht die Anmeldedaten der jeweiligen Sitzungsbenutzer überschreiben können. Gehostete OAuth-/Service-Routing-Anmeldedaten für Harness-Plattform-APIs authentifizieren keine direkten Split.io-Anfragen. fme_feature_flag unterstützt im Legacy-Modus die vollständige Lebenszyklusverwaltung: Erstellen (erfordert traffic_type_id), Auflisten, Abrufen, Aktualisieren von Metadaten, Löschen sowie die Execute-Aktionen Kill/Restore/Reallocate/Archive/Unarchive. Verwende fme_traffic_type, um Traffic-Type-IDs zu ermitteln, fme_identity, um Identitätsattribute zu erstellen/aktualisieren, und fme_standard_segment / fme_segment_keys, um Standardsegmente zu prüfen und Mitgliedsschlüssel hinzuzufügen. fme_rule_based_segment bietet CRUD für Targeting-Segmente, während fme_rule_based_segment_definition umgebungsspezifische Segmentregeln mit Aktivierungs-/Deaktivierungs- und Genehmigungsabläufen für Änderungsanfragen verwaltet.

GitOps

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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 Engineering

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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

Cloud Cost Management (CCM)

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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

Software Engineering Insights (SEI)

SEI-Ressourcen sind zur Token-Effizienz zusammengefasst. Verwenden Sie die Parameter metric oder aspect für DORA-, Team-/Org-Tree-Details und KI-Einblicke.

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
sei_metric	x
sei_productivity_metric		x
sei_dora_metric		x				metric: deployment_frequency, change_failure_rate, mttr, lead_time oder *_drilldown übergeben
sei_team	x	x
sei_team_detail	x					aspect: integrations, developers, integration_filters übergeben
sei_org_tree	x	x
sei_org_tree_detail	x	x				aspect: efficiency_profile, productivity_profile, business_alignment_profile, integrations, teams übergeben
sei_business_alignment	x	x				aspect: feature_metrics, feature_summary, drilldown für get übergeben
sei_ai_usage	x	x				aspect: metrics, breakdown, summary, top_languages übergeben
sei_ai_adoption	x	x				aspect: metrics, breakdown, summary übergeben
sei_ai_impact		x				aspect: pr_velocity, rework übergeben
sei_ai_raw_metric	x

Software-Lieferkettenabsicherung (SCS)

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
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 speichert in-toto-Bestätigungen (SDLC-Nachweise). List unterstützt den Geltungsbereich für Konto/Organisation/Projekt über resource_scope. Einfache Freitextfilter (pipeline, artifact allein, gitoid) verwenden search_term; eine zusätzliche Name-Bedingung verwendet filters.subject_name; der Inhaltsdigest des Subjekts verwendet filters.subject_digest. Get sucht anhand von gitoid_sha256 und erfordert org_id/project_id (aus der Listenzeile). Download (Aktion download von harness_execute) gibt einen zeitlich begrenzten download_url zurück — zeigen Sie diesen Link dem Benutzer immer an. Erfordert das Feature-Flag SCS_EVIDENCE_VAULT.

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
attestation	x	x				download

Sicherheitsprüfungsorchestrierung (STO)

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
security_issue	x
security_issue_filter	x
security_exemption	x		x			approve, reject
remediation_diff	x

Das Erstellen von security_exemption ist ein high_write-Vorgang. Der Server leitet requester_id aus dem authentifizierten PAT ab, setzt exemptFutureOccurrences=true und verwendet standardmäßig den Wert 30 für duration_days, wenn dieser nicht angegeben ist. Um Ausnahmen aufzulisten, übergeben Sie eine kleine explizite Seitengröße (zum Beispiel filters: { "status": "Pending", "size": 5 }) und folgen Sie dem in jeder Antwort zurückgegebenen _nextPageHint.

Workflow zum Ausführen von Sicherheitsausnahmen:

• Verwenden Sie harness_list mit resource_type="security_exemption" und einem expliziten status, etwa Pending, Approved, Rejected, Expired oder Canceled.
• Verwenden Sie harness_execute mit action="approve" und einem erforderlichen body.scope: CURRENT, ACCOUNT, ORG oder PROJECT. CURRENT genehmigt die Ausnahme in ihrem bestehenden Geltungsbereich; für die anderen Geltungsbereiche wird intern der STO-Promote-Endpunkt verwendet. Wenn body.approver_id nicht angegeben ist, füllt der Server es automatisch mit dem authentifizierten Benutzer aus; body.comment ist optional.
• Verwenden Sie action="reject", um eine Ausnahme abzulehnen. Wenn body.approver_id nicht angegeben ist, wird es ebenfalls automatisch ausgefüllt.
• Es gibt keine separate Execute-Aktion promote. Verwenden Sie action="approve" mit einem nicht-CURRENT-body.scope, wenn das gewünschte Ergebnis eine Genehmigung auf Konto-, Organisations- oder Projektebene ist.

Zugriffskontrolle

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
user	x	x
user_group	x	x	x	x	x
service_account	x	x	x		x
role	x	x	x		x
role_assignment	x		x
resource_group	x	x	x		x
permission	x

Governance

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
policy	x	x	x	x	x
policy_set	x	x	x	x	x
policy_evaluation	x	x

Deployment-Freeze

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
freeze_window	x	x	x	x	x	toggle_status
global_freeze		x				manage

Service-Überschreibungen

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
service_override	x	x	x	x	x

Einstellungen

Ressourcentyp	Auflisten	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
setting	x

MCP-Prompts

DevOps

Prompt	Beschreibung	Parameter
build-deploy-app	End-to-End-CI/CD-Workflow: Git-Repository scannen, CI-Pipeline generieren (Docker-Image erstellen und pushen), K8s-Manifeste ermitteln oder generieren, CD-Pipeline erstellen und bereitstellen – mit automatischen Wiederholungsversuchen bei CI-Fehlern (bis zu 5 Versuche) und CD-Fehlern (bis zu 3 Versuche mit Zustimmung des Benutzers). Sind alle Wiederholungsversuche ausgeschöpft, werden Harness-UI-Deep-Links zu allen erstellten Ressourcen für die manuelle Untersuchung bereitgestellt.	repoUrl (erforderlich), imageName (erforderlich), projectId (optional), namespace (optional)
debug-pipeline-failure	Eine fehlgeschlagene Ausführung analysieren: Akzeptiert eine Ausführungs-ID, Pipeline-ID oder Harness-URL. Ruft die Aufschlüsselung nach Stages/Steps, Fehlerdetails, Delegate-Informationen und Protokolle fehlgeschlagener Steps über harness_diagnose ab und liefert anschließend eine Ursachenanalyse sowie Lösungsvorschläge. Verfolgt automatisch verkettete Pipeline-Fehler.	executionId (optional), projectId (optional)
pipeline_summarizer	ALLE Step-Protokolle einer Pipeline-Ausführung abrufen und zusammenfassen. Verwendet harness_diagnose mit include_logs: true, include_all_step_logs: true, um die Protokolle aller Steps abzurufen, und stellt anschließend eine Tabelle mit Step-Name, Status, Dauer und Ereignis (protokollbasierte Zusammenfassung) bereit. Lässt KEINE Steps aus.	executionId (optional), projectId (optional)
create-pipeline	Aus natürlichsprachlichen Anforderungen ein neues Pipeline-YAML generieren und vorhandene Ressourcen als Kontext prüfen	description (erforderlich), projectId (optional)
create-agent	Interaktiv einen Harness-AI-Agent erstellen – vorhandene Agents prüfen (beim Aktualisieren das aktuelle Format der agent.uses-Spezifikation vom älteren Format der agent.step.group.steps-Spezifikation unterscheiden), Anforderungen erfassen, die Agent-Spezifikation im passenden Format generieren, mit dem Benutzer abstimmen und anschließend über harness_create/harness_update erstellen oder aktualisieren	agent_name (erforderlich), task_description (erforderlich), org_id (optional), project_id (optional)
onboard-service	Schrittweise durch das Onboarding eines neuen Service mit Umgebungen und einer Deployment-Pipeline führen	serviceName (erforderlich), projectId (optional)
dora-metrics-review	DORA-Metriken (Deployment-Frequenz, Änderungsfehlerrate, MTTR, Durchlaufzeit) mit Einstufung als Elite/High/Medium/Low und Empfehlungen zur Verbesserung prüfen	teamRefId (optional), dateStart (optional), dateEnd (optional)
setup-gitops-application	Durch das Onboarding einer GitOps-Anwendung führen – Agent, Cluster und Repository überprüfen und die Anwendung erstellen	agentId (erforderlich), projectId (optional)
chaos-resilience-test	Ein Chaos-Experiment entwerfen, um die Resilienz eines Service mit Fehlerinjektionen, Probes und erwarteten Ergebnissen zu testen	serviceName (erforderlich), projectId (optional)
feature-flag-rollout	Einen schrittweisen Rollout eines Feature-Flags über Umgebungen hinweg mit Sicherheitsprüfungen planen und ausführen	flagIdentifier (erforderlich), projectId (optional)
migrate-pipeline-to-template	Eine vorhandene Pipeline analysieren und daraus wiederverwendbare Stage-/Step-Vorlagen extrahieren	pipelineId (erforderlich), projectId (optional)
delegate-health-check	Delegate-Konnektivität, Zustand und Token-Status prüfen sowie Infrastrukturprobleme beheben	projectId (optional)
developer-portal-scorecard	IDP-Scorecards für Services prüfen und Lücken zur Verbesserung der Developer Experience ermitteln	projectId (optional)
pending-approvals	Auf Genehmigung wartende Pipeline-Ausführungen finden, Details anzeigen und Genehmigung oder Ablehnung anbieten	projectId (optional), orgId (optional), pipelineId (optional)

FinOps

Prompt	Beschreibung	Parameter
optimize-costs	Cloud-Kostendaten analysieren, Empfehlungen und Anomalien aufzeigen und nach potenziellen Einsparungen priorisieren	projectId (optional)
cloud-cost-breakdown	Cloud-Kosten nach Service, Umgebung oder Cluster detailliert untersuchen, einschließlich Trendanalyse und Anomalieerkennung	perspectiveId (optional), projectId (optional)
commitment-utilization-review	Auslastung von Reserved Instances und Savings Plans analysieren, um Verschwendung zu erkennen und Verpflichtungen zu optimieren	projectId (optional)
cost-anomaly-investigation	Kostenanomalien untersuchen – Ursache, betroffene Ressourcen und Abhilfemaßnahmen ermitteln	projectId (optional)
rightsizing-recommendations	Empfehlungen zur Rightsizing-Optimierung prüfen und priorisieren, optional Jira- oder ServiceNow-Tickets erstellen	projectId (optional), minSavings (optional)

DevSecOps

Prompt	Beschreibung	Parameter
security-review	Sicherheitsprobleme in Harness-Ressourcen prüfen und nach Schweregrad geordnete Abhilfemaßnahmen vorschlagen	projectId (optional), severity (optional, Standard: critical,high)
vulnerability-triage	Sicherheitslücken in Pipelines und Artefakten priorisieren und nach Schweregrad und Ausnutzbarkeit einstufen	projectId (optional), severity (optional)
sbom-compliance-check	SBOM- und Compliance-Status von Artefakten prüfen – Lizenzrisiken, Richtlinienverstöße und Komponenten-Sicherheitslücken	artifactId (optional), projectId (optional)
supply-chain-audit	End-to-End-Sicherheitsaudit der Software-Lieferkette – Herkunft, Nachweiskette und Richtlinienkonformität	projectId (optional)
security-exemption-review	Ausstehende Sicherheitsausnahmen prüfen und Entscheidungen zur Sammelgenehmigung oder -ablehnung treffen	projectId (optional)
bulk-exemption-create	Begründete Sicherheitsausnahmen für mehrere STO-Probleme mit klar definiertem Umfang und Hinweisen zur Dauer erstellen	projectId (erforderlich), exemption_type (erforderlich), reason (erforderlich), issue filters (optional)
access-control-audit	Benutzerberechtigungen, übermäßig privilegierte Konten und Rollenzuweisungen prüfen, um das Prinzip der geringsten Berechtigung durchzusetzen	projectId (optional), orgId (optional)

Harness Code

Prompt	Beschreibung	Parameter
code-review	Einen Pull Request überprüfen — Diff, Commits, Prüfungen und Kommentare analysieren, um strukturiertes Feedback zu Fehlern, Sicherheit, Leistung und Stil bereitzustellen	repoId (erforderlich), prNumber (erforderlich), projectId (optional)
pr-summary	Automatisch einen PR-Titel und eine Beschreibung aus dem Commit-Verlauf und dem Diff eines Branches generieren	repoId (erforderlich), sourceBranch (erforderlich), targetBranch (optional, Standard: main), projectId (optional)
branch-cleanup	Branches in einem Repository analysieren und veraltete oder zusammengeführte Branches zum Löschen empfehlen	repoId (erforderlich), projectId (optional)

MCP-Ressourcen

Ressourcen-URI	Beschreibung	MIME-Typ
pipeline:///{pipelineId}	YAML-Definition der Pipeline	application/x-yaml
pipeline:///{orgId}/{projectId}/{pipelineId}	YAML der Pipeline (mit explizitem Geltungsbereich)	application/x-yaml
executions:///recent	Zusammenfassungen der letzten 10 Pipeline-Ausführungen	application/json
schema:///pipeline	JSON-Schema der Harness-Pipeline	application/schema+json
schema:///template	JSON-Schema der Harness-Vorlage	application/schema+json
schema:///trigger	JSON-Schema des Harness-Triggers	application/schema+json
schema:///pipeline_v1 (Alpha)	JSON-Schema der Harness-V1-Pipeline (vereinfachtes Format für Stages/Steps)	application/schema+json
schema:///agent-pipeline	JSON-Schema der Harness-KI-Agent-Pipeline	application/schema+json
agent-docs:///legacy-format	Referenz für das Legacy-Agent-Spezifikationsformat (agent.step.group.steps / PLUGIN_TASK), das von der Eingabeaufforderung create-agent beim Aktualisieren eines vorhandenen Agents im Legacy-Format gelesen wird	text/markdown

Toolset-Filterung

Standardmäßig sind 44 von 50 Toolsets aktiviert. Fünf Toolsets sind optional und standardmäßig ausgeschlossen:

• ansible — Harness Ansible (Inventare, Playbooks, Hosts, Aktivitäten). Optional, da es projektbezogen ist und Konzepte hinzufügt, die viele Benutzer nicht benötigen.
• appsec — Traceable Application & API Security (API-Inventar, OpenAPI-Spezifikationen, Beispiel-Spans, sensible Datentypen, Laufzeit-Bedrohungsaktivitäten, Sicherheitsereignisse, AST-Scans und Inventartrends). Optional, da es ein dediziertes HARNESS_APPSEC_API_KEY erfordert und auf api.traceable.ai ausgerichtet ist.
• autonomous_work — Development Harness (autonomes Arbeiten). Optional; den Geltungsbereich finden Sie in der Toolset-Beschreibung.
• observability-evaluations — Geplante Regeln zur Auswertung von Produktions-Telemetriedaten. Optional, da es von der bereitgestellten Scoring-Control-Plane abhängt.
• unified-search — Semantische Suche über alle Quellen, die der Suchdienst bereitstellt. Optional, da das Backend nicht auf jedem Cluster bereitgestellt ist und pro Konto über ein Feature-Flag aktiviert wird (siehe Unified Search).
• registries-v3 — Harness Artifact Registry v3 (Pakete, Versionen, Dateien, Metadaten, Scans, Firewall-Ausnahmen). Optional, bis v3-Schreibvorgänge verfügbar sind, damit Agents nicht zwischen v1-Registries/Artefakten und v3-Paketen/Versionen unterscheiden müssen.

Toolsets mit dem Präfix + hinzufügen

Verwenden Sie das Präfix +, um optionale Toolsets zusätzlich zu allen Standard-Toolsets explizit einzuschließen:

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

Standard-Toolsets entfernen

Verwenden Sie das Präfix -, um nicht benötigte Toolsets auszuschließen:

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

+ und - kombinieren

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

Explizite Zulassungsliste

Eine explizite, durch Kommas getrennte Liste (ohne Präfixe) ersetzt die Standardwerte vollständig. Nur die aufgeführten Toolsets sind aktiviert:

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

Verfügbare Toolset-Namen:

Toolset	Ressourcentypen
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	Einstellung
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

Architektur

                 +------------------+
                 |   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 |
                 +-------------------+

Funktionsweise

1. Tools sind allgemeine Verben: harness_list, harness_get usw. Sie akzeptieren einen Parameter resource_type, der an den richtigen API-Endpunkt weiterleitet.
2. Die Registry ordnet jedem resource_type ein ResourceDefinition zu — eine deklarative Datenstruktur, die HTTP-Methode, URL-Pfad, Zuordnungen von Pfad-/Abfrageparametern und die Logik zur Extraktion der Antwort angibt.
3. Dispatch löst die Ressourcendefinition auf, erstellt die HTTP-Anfrage (Pfadersetzung, Abfrageparameter, resource_scope-bewusste Injektion von Konto/Organisation/Projekt), ruft die Harness API über HarnessClient auf und extrahiert die relevanten Antwortdaten.
4. Die Toolset-Filterung (HARNESS_TOOLSETS) steuert, welche Ressourcendefinitionen beim Start in die Registry geladen werden.
5. Strukturierte Ausgabe wird mit MCP outputSchema deklariert; harness_list wandelt Arrays und gängige Listen-Wrapper für strikte Clients in objektförmige structuredContent um.
6. Deep Links werden automatisch an Antworten angehängt und stellen direkte Harness-UI-URLs für jede Ressource bereit.
7. Der Kompaktmodus entfernt ausführliche Metadaten aus Listenergebnissen und behält nur umsetzbare Felder bei (Identität, Status, Typ, Zeitstempel, Deep Links), um den Tokenverbrauch zu minimieren.

Einen neuen Ressourcentyp hinzufügen

Erstelle eine neue Datei in src/registry/toolsets/ oder füge eine Ressource zu einem vorhandenen Toolset hinzu:

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

Importiere sie anschließend in src/registry/index.ts und füge sie dem Array ALL_TOOLSETS hinzu. Änderungen an Tool-Dateien sind nicht erforderlich.

Entwicklung

# 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

Projektstruktur

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

Abfrage

Die Schreib-Tools (harness_create, harness_update, harness_delete, harness_execute) verwenden MCP elicitation, um den Benutzer um Bestätigung zu bitten, wenn das Risiko der Aktion dies erfordert — nur bei Vorgängen mit medium_write, high_write und destructive. Erstellungen, Aktualisierungen und Lesevorgänge mit geringem Risiko (z. B. pipeline.create, pipeline.update, hql_query.run) werden ohne Nachfrage ausgeführt. Wird eine Nachfrage angezeigt, sieht der Benutzer, was gleich geschieht, und kann zustimmen oder ablehnen. So wird für Vorgänge, die tatsächlich Änderungen vornehmen oder etwas ausführen, eine echte Freigabe durch einen Menschen gewährleistet.

Funktionsweise:

1. Das LLM ruft ein Schreib-Tool mit einem Risiko von medium_write oder höher auf (z. B. harness_delete, harness_execute pipeline.run). Erstellungen, Aktualisierungen und Lesevorgänge mit geringem Risiko lösen keine Nachfrage aus.
2. Der Server sendet dem Client eine Abfrageanfrage mit einer Zusammenfassung des Vorgangs und einem Kontrollkästchen confirm (standardmäßig aktiviert).
3. Der Benutzer sieht die Details und klickt auf Akzeptieren (mit aktiviertem confirm) oder Ablehnen / Abbrechen.
4. Wird der Vorgang mit confirm: true akzeptiert, wird er ausgeführt. Wird er mit deaktiviertem confirm akzeptiert, abgelehnt oder abgebrochen, wird er blockiert und das LLM darüber informiert (eine ausdrückliche Ablehnung ist maßgeblich und wird nicht durch confirm: true beim Tool-Aufruf umgangen).

Client-Unterstützung:

Client	Unterstützung für Abfragen
Cursor	Ja
VS Code (Copilot)	Ja
Claude Desktop	Noch nicht
Devin Desktop	Noch nicht
MCP Inspector	Ja

Das Verhalten bei Abfragen hängt vom Risiko des Vorgangs ab, wenn die Client-Unterstützung fehlt:

Risikostufe	Client unterstützt Abfragen	confirm: true übergeben	Verhalten
read, low_write	beliebig	beliebig	Ohne Nachfrage fortfahren — es wird keine Nachfrage angezeigt (confirm hat auf dieser Risikostufe keine Wirkung)
medium_write, high_write, destructive	Ja	beliebig	Benutzer fragen. Nur fortfahren, wenn der Benutzer mit confirm: true zustimmt (Standardwert des Schemas). Eine ausdrückliche Ablehnung, ein Abbruch oder eine Zustimmung mit confirm: false (der Benutzer hat das Kontrollkästchen deaktiviert) ist maßgeblich und wird nicht durch confirm: true beim Tool-Aufruf umgangen. Eine Zustimmung ohne das Feld confirm gilt als Hinweis darauf, dass der Client keine verwendbare Nachfrage angezeigt hat — dies lässt sich durch einen erneuten Versuch mit confirm: true beheben
medium_write, high_write, destructive	Nein	Nein	BLOCKIEREN (Fehler mit Hinweis auf einen erneuten Versuch mit confirm: true zurückgeben)
medium_write, high_write, destructive	Nein	Ja	Fortfahren (ausdrückliche Zustimmung für nicht interaktive Automatisierung)
beliebig (auf oder unter HARNESS_AUTO_APPROVE_RISK)	beliebig	beliebig	Automatisch genehmigen, ohne nachzufragen

Wenn elicitInput zur Laufzeit bei einem Vorgang mit einem Risiko von medium_write oder höher fehlschlägt (Transportfehler, nicht unterstützte Methode), wird der Aufruf blockiert, sofern der Aufrufer nicht confirm: true übergibt. confirm: true wird als Ausweichoption berücksichtigt, wenn der Client keine Nachfrage anzeigen konnte oder eine unvollständige Zustimmung zurückgegeben hat ({action: "accept"} ohne Bestätigungsfeld). Eine ausdrückliche Ablehnung oder ein Abbruch durch einen Client, der den Abfrage-Handshake abgeschlossen hat, wird dadurch jedoch nicht übergangen.

Autonomer Modus

Autonomer Modus bedeutet, dass der Server alle Vorgänge — einschließlich Schreibvorgängen und destruktiver Aktionen — ohne Bestätigungsabfrage ausführt. Aktiviere ihn mit folgender Einstellung:

HARNESS_AUTO_APPROVE_RISK=all

Dies ist die Obergrenze auf Bereitstellungsebene: Sobald sie festgelegt ist, können einzelne Sitzungen sie nicht überschreiten (sie können jedoch über den Header x-harness-auto-approve-risk pro Sitzung einen strengeren Schwellenwert festlegen).

Oder in der Konfiguration deines MCP-Clients:

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

Teilautonomie: Du kannst auch nur Vorgänge bis zu einer bestimmten Risikostufe automatisch genehmigen lassen und bei Vorgängen mit höherem Risiko weiterhin nachfragen:

# 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

Wert	Was automatisch genehmigt wird
none (Standard)	Nichts — kein Schwellenwert für automatische Genehmigungen
low_write	Lesevorgänge und Schreibvorgänge mit geringem Risiko
medium_write	Lesevorgänge sowie Schreibvorgänge mit geringem und mittlerem Risiko
high_write	Lesevorgänge sowie Schreibvorgänge mit geringem, mittlerem und hohem Risiko
all	Alles, einschließlich destruktiver Vorgänge

Warnung zum autonomen Modus: HARNESS_AUTO_APPROVE_RISK=all überspringt die Bestätigung für alle Vorgänge, einschließlich harness_delete. Mit Vorsicht verwenden und erwägen, die verfügbaren Ressourcentypen mit HARNESS_TOOLSETS einzuschränken.

Hinweis zur Migration: HARNESS_SKIP_ELICITATION=true wird weiterhin unterstützt und HARNESS_AUTO_APPROVE_RISK=all zugeordnet. Eine Warnung zur Einstellung wird in stderr protokolliert. Wenn beide gesetzt sind, hat HARNESS_AUTO_APPROVE_RISK Vorrang.

Sicherheit

• Geheimnisse werden niemals offengelegt. Der Ressourcentyp secret gibt nur Metadaten zurück (Name, Typ, Geltungsbereich) — geheime Werte sind in keiner Antwort enthalten.
• Bei Vorgängen, die eine Bestätigung erfordern, wird nach Möglichkeit eine Abfrage verwendet. Wenn für eine Schreib- oder Ausführungsaktion ein Risiko von medium_write, high_write oder destructive besteht, versuchen harness_create, harness_update, harness_delete und harness_execute, vor der Ausführung eine MCP-Abfrage durchzuführen (siehe Abfrage). Aktionen mit geringem Risiko (read, low_write — z. B. pipeline.create, pipeline.update, hql_query.run) werden ohne Nachfrage ausgeführt.
• Vorgänge mit mittlerem oder höherem Risiko werden standardmäßig blockiert. Wenn für Vorgänge mit medium_write, high_write oder destructive keine Bestätigung eingeholt werden kann, werden sie blockiert, statt blind ausgeführt zu werden. Für autonome Workflows kann dies mit HARNESS_AUTO_APPROVE_RISK überschrieben werden.
• CORS ist auf denselben Ursprung beschränkt. Der HTTP-Transport lässt nur Anfragen desselben Ursprungs zu und verhindert so CSRF-Angriffe von bösartigen Websites, die auf den MCP-Server auf localhost abzielen.
• HTTP-Ratenbegrenzung. Der HTTP-Transport begrenzt Anfragen auf 60 pro Minute und IP-Adresse, um eine Überlastung durch Anfragen zu verhindern.
• API-Ratenbegrenzung. Der Harness API-Client begrenzt Anfragen auf 10 pro Sekunde, um eine Überschreitung der Upstream-Ratenbegrenzungen zu vermeiden.
• Seitennummerierung ist begrenzt. Listenabfragen sind auf insgesamt 10.000 Elemente und 100 Elemente pro Seite begrenzt, um eine Erschöpfung des Arbeitsspeichers zu verhindern.
• Wiederholungsversuche mit Backoff. Vorübergehende Fehler (HTTP 429, 5xx) werden mit exponentiellem Backoff und Jitter erneut versucht.
• Bindung an localhost. Der HTTP-Transport bindet standardmäßig an 127.0.0.1 — er ist nicht über das Netzwerk erreichbar.
• Keine Protokollierung auf stdout. Alle Protokolle werden nach stderr geschrieben, damit der stdio-JSON-RPC-Transport nicht beschädigt wird.

Ergänzende Skills

Der Harness MCP-Server lässt sich gut mit Harness Skills kombinieren — einer Sammlung sofort einsatzbereiter Claude-Code-Skills (Slash-Befehle) für gängige Harness-Workflows. Installiere sie zusammen mit diesem MCP-Server, um Automatisierungen auf höherer Ebene wie /deploy, /rollback, /triage und mehr zu nutzen, ohne eigene Prompts schreiben zu müssen.

Fehlerbehebung und häufige Fallstricke

Symptom	Wahrscheinliche Ursache	Maßnahme
HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...	API-Schlüssel hat kein unterstütztes kontogebundenes Format (pat.<accountId>... oder sat.<accountId>...), daher kann die Konto-ID nicht abgeleitet werden	HARNESS_ACCOUNT_ID explizit festlegen
Unknown transport: "..." beim Start	Nicht unterstütztes CLI-Transportargument	Nur stdio oder http verwenden
Invalid HARNESS_TOOLSETS: ... beim Start	Ein oder mehrere Toolset-Namen werden nicht erkannt	Nur Namen aus Toolset Filtering verwenden (exakte Übereinstimmung)
HTTP mcp-session-id header is required...	Eine Sitzungsanfrage wurde ohne Sitzungsheader gesendet	Zuerst initialize senden, dann mcp-session-id bei POST/GET/DELETE /mcp einschließen
HTTP Session not found...	Sitzung ist nach MCP_SESSION_TTL_MS Millisekunden Inaktivität abgelaufen oder wurde bereits geschlossen	initialize erneut ausführen, um eine neue Sitzung zu erstellen, und dann mit einem neuen Header wiederholen
HTTP 405 Method Not Allowed bei /mcp	Nicht unterstützte Methode für den MCP-Endpunkt	Nur POST, GET, DELETE oder OPTIONS verwenden
HTTP Invalid request	Ungültiger JSON-Body oder Request-Body überschreitet HARNESS_MAX_BODY_SIZE_MB	JSON-Payload-Größe und -Struktur überprüfen; bei Bedarf HARNESS_MAX_BODY_SIZE_MB erhöhen
Unknown resource_type "..." von Tools	Ressourcentyp ist falsch geschrieben oder wurde über HARNESS_TOOLSETS herausgefiltert	harness_describe (optional mit search_term) aufrufen, um gültige Typen zu ermitteln
Missing required field "... for path parameter ..."	Bei einem projekt- oder organisationsbezogenen Aufruf fehlen Bezeichner	HARNESS_ORG/HARNESS_PROJECT festlegen oder org_id/project_id pro Tool-Aufruf übergeben
resource_scope "org" requires org_id... oder resource_scope "project" requires project_id...	Eine Ressource mit mehreren Geltungsbereichen wurde ohne ausreichende Bezeichner auf den Organisations- oder Projektbereich beschränkt	Fehlende org_id/project_id übergeben, HARNESS_ORG/HARNESS_PROJECT konfigurieren oder, sofern unterstützt, resource_scope: "account" verwenden
Read-only mode is enabled ... operations are not allowed	HARNESS_READ_ONLY=true verhindert Erstellen/Aktualisieren/Löschen/Ausführen	HARNESS_READ_ONLY=false festlegen, wenn Schreibvorgänge beabsichtigt sind
Pipeline-Ausführung scheitert bei der Vorabprüfung aufgrund nicht aufgelöster erforderlicher Eingaben	Die bereitgestellten inputs deckten nicht alle erforderlichen Laufzeit-Platzhalter ab	runtime_input_template abrufen, fehlende einfache Schlüssel angeben oder für strukturierte Eingaben input_set_ids verwenden
Pipeline-CI-Kurzform (branch, tag, pr_number, commit_sha) wurde nicht angewendet	inputs.build wurde bereits angegeben, daher wurde die Kurzform-Erweiterung absichtlich übersprungen	inputs.build entfernen, um die Kurzform-Erweiterung zu verwenden, oder die vollständige explizite Struktur von build beibehalten
Pipeline-Ausführung hat die falsche YAML-Revision geladen	Die Pipeline-Definition ist in Git gespeichert und bei der Ausführung wurde nicht der gewünschte Pipeline-Branch angegeben	params.pipeline_branch bei der Aktion run übergeben; dies entspricht Harness branch
wait: true gab _wait.error zurück	Der Pipeline-Trigger war erfolgreich, aber die serverseitige Abfrage schlug fehl	Den execution_id mit harness_get(resource_type="execution", ...) erneut prüfen, bevor entschieden wird, ob die Ausführung wiederholt werden soll
wait: true gab execution_timed_out: true zurück	Die Ausführung erreichte vor wait_timeout_seconds keinen Endstatus	Den zurückgegebenen execution_id verwenden, um den Status erneut zu prüfen; vor dem Ausführen von harness_diagnose auf einen Endstatus warten
Ausführungsprotokolle sind leer oder Blob-Downloads geben 403 zurück	Für von Harness gehostete Protokoll-Blob-URLs ist der konfigurierte Harness-Client-/Authentifizierungspfad erforderlich, insbesondere bei internen oder selbstverwalteten Hosts	HARNESS_BASE_URL auf den Ziel-Harness-Host ausgerichtet lassen und harness_get(resource_type="execution_log", ...) oder harness_diagnose(..., include_logs=true) verwenden, statt den MCP-Client zu umgehen
Operation declined by user / Operation cancelled by user	Benutzer hat den Bestätigungsdialog zur Abfrage abgelehnt oder abgebrochen — maßgeblich	Vorgangsdetails mit dem Benutzer überprüfen; confirm: true umgeht keine ausdrückliche Ablehnung. Der Benutzer muss der Aufforderung zustimmen
Operation blocked: the client could not surface a usable confirmation prompt	Der Client unterstützt keine Abfragen, elicitInput ist fehlgeschlagen oder hat eine degenerierte Zustimmung zurückgegeben	Für nicht interaktive Automatisierung mit confirm: true erneut versuchen oder einen Client verwenden, der Abfragen unterstützt
body.template_yaml (or body.yaml) is required für das Erstellen/Aktualisieren von Vorlagen	Vorlagen-APIs erwarten eine vollständige YAML-Payload	Vollständigen template_yaml-String in body angeben; zum Löschen version_label übergeben, um eine Version zu löschen (weglassen, um alle Versionen zu löschen)
HARNESS_BASE_URL must use HTTPS beim Start	HARNESS_BASE_URL ist auf eine HTTP-URL gesetzt	HTTPS verwenden oder für die lokale Entwicklung HARNESS_ALLOW_HTTP=true festlegen

Lizenz

MIT