Harness

Harness MCP Server 2.0

Ein MCP-Server (Model Context Protocol), der KI-Agenten über 11 konsolidierte Tools und 255 Ressourcentypen vollen Zugriff auf die Harness.io-Plattform bietet.

Warum dieser MCP-Server

Die meisten MCP-Server bilden ein Tool pro API-Endpunkt ab. Für eine Plattform so breit wie Harness bedeutet das 240+ Tools – und LLMs werden bei der Tool-Auswahl schlechter, je größer die Anzahl wird. Kontextfenster füllen sich mit Schemas, und jeder neue Endpunkt bedeutet neuen Code.

Dieser Server ist anders aufgebaut:

• 11 Tools, 255 Ressourcentypen. Ein registry-basiertes Dispatch-System leitet harness_list, harness_get, harness_create usw. an jede Harness-Ressource weiter – Pipelines, Services, Umgebungen, Orgs, Projekte, Feature Flags, Kostendaten und mehr. Das LLM wählt aus 11 Tools statt aus Hunderten.
• Volle Plattformabdeckung. 41 Standard-Toolsets für CI/CD, GitOps, Feature Flags, Cloud-Kostenmanagement, Security-Testing, Chaos-Engineering, Database-DevOps, Internes Entwicklerportal, Software-Lieferkette, Infrastructure-as-Code-Management, Release-Management, Governance, Service-Overrides, Wissensgraph und mehr. Opt-in-Ansible- und Observability-Evaluierungsabdeckung ist bei Bedarf verfügbar.
• Multi-Projekt-Workflows sofort einsatzbereit. Agenten entdecken Organisationen und Projekte dynamisch – keine hartcodierten Umgebungsvariablen nötig. Fragen Sie „Zeige fehlgeschlagene Ausführungen über alle Projekte hinweg“ und der Agent kann die gesamte Kontenhierarchie navigieren.
• 35 Prompt-Vorlagen. Vorgefertigte Prompts für häufige Workflows: Build- und Deploy-Anwendungen Ende-zu-Ende, fehlgeschlagene Pipelines debuggen, DORA-Metriken überprüfen, Schwachstellen triagieren, Cloud-Kosten optimieren, Zugriffskontrolle auditieren, 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-/gemeinsame Bereitstellungen, Docker- und Kubernetes-bereit.
• Null-Konfigurations-Start. Stellen Sie einfach einen Harness-API-Schlüssel bereit. Die Konten-ID wird automatisch aus PAT- und SAT-Tokens extrahiert, Org-/Projekt-Standardwerte sind optional, und die Toolset-Filterung ermöglicht es Ihnen, nur das freizugeben, was Sie benötigen.
• Von Natur aus erweiterbar. Das Hinzufügen einer neuen Harness-Ressource bedeutet das Hinzufügen einer deklarativen Datendatei – keine neue Tool-Registrierung, keine Schemaänderungen, keine Prompt-Updates.

Voraussetzungen

Vor der Installation oder Ausführung des Servers benötigen Sie einen Harness-API-Schlüssel:

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

Detaillierte Anweisungen finden Sie im Harness-API-Schnellstart.

Schnellstart

Option 0: Gehostetes Harness MCP

Wenn Ihr Harness-Konto den gehosteten MCP-Dienst aktiviert hat, können Clients, die Remote-MCP-Server unterstützen, sich direkt mit dem verwalteten Endpunkt verbinden, anstatt den Server lokal auszuführen.

Wichtig: Der gehostete MCP-Dienst verwendet Harness-Platform-OAuth, nicht HARNESS_API_KEY. Er muss außerdem pro Konto von Harness-Support aktiviert/konfiguriert werden, bevor der Endpunkt verwendet werden kann.

Siehe Gehostetes Harness MCP für Konfigurationsbeispiele.

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 Client-Konfiguration unten).

# 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 Konten-ID wird automatisch aus PAT- und SAT-Tokens extrahiert (pat.<accountId>... oder sat.<accountId>...), daher ist HARNESS_ACCOUNT_ID nur für API-Schlüssel ohne eingebettetes Kontensegment erforderlich.

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

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-Verzeichnis-Bundle

Das MCPB-Bundle-Manifest befindet sich in [mcp-directory/](mcp-directory/), und das 512×512-Bundle-Symbol wird unter [icon.png](icon.png) im Repository-Stammverzeichnis verfolgt. Das gepackte Archiv enthält manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json auf Stammebene und Produktions-node_modules/.

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

pnpm prepare:mcpb

Das Staging-Verzeichnis wird nach dist/mcpb/ geschrieben, mit Produktionsabhängigkeiten, die aus npm-shrinkwrap.json mit dem flachen Layout von npm installiert werden. Die gepinnte offizielle MCPB-CLI validiert es und erstellt dist/harness-mcp-server-<version>.mcpb.

Versionstags, die v*.*.* entsprechen, veröffentlichen dieses Bundle automatisch im entsprechenden GitHub-Release. Um ein bestehendes Release ohne erneutes Veröffentlichen von npm nachzupflegen, führen Sie den Release-Workflow manuell mit seiner release_tag-Eingabe aus (zum Beispiel v3.2.20). Der Workflow checkt genau diesen Tag aus und erstellt ihn, bevor er nur sein versioniertes MCPB-Asset ersetzt.

CLI-Nutzung

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

Der Transport standardmäßig auf stdio, wenn nicht angegeben. Verwenden Sie http für Remote-/gemeinsame Bereitstellungen.

HTTP-Transport

Wenn der Server im HTTP-Modus läuft, stellt er Folgendes bereit:

Endpunkt	Methode	Beschreibung
/mcp	POST	MCP-JSON-RPC-Endpunkt (Initialisierung + Sitzungsanfragen)
/mcp	GET	SSE-Stream für serverinitiierte Nachrichten (Fortschritt, Elicitation)
/mcp	DELETE	Beendet eine aktive MCP-Sitzung
/mcp	OPTIONS	CORS-Preflight
/health	GET	Health-Check – gibt { "status": "ok", "sessions": <count> } zurück
/.well-known/oauth-protected-resource	GET	RFC-9728-Metadaten, wenn HARNESS_MCP_MODE=oauth
/.well-known/oauth-protected-resource/mcp	GET	Pfadbewusste RFC-9728-Metadaten für die Standard-/mcp-Ressource

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:

• Setzen Sie HARNESS_MCP_AUTH_TOKEN für gemeinsame oder remote erreichbare Einzelbenutzer- und Mehrbenutzer-Bereitstellungen. Wenn gesetzt, muss jede POST-, GET- und DELETE-Anfrage an /mcp Authorization: Bearer <token> enthalten.
• Der OAuth-Modus akzeptiert HarnessID-Zugriffstokens anstelle von HARNESS_MCP_AUTH_TOKEN und kann an eine Nicht-Loopback-Adresse gebunden werden, ohne den nicht authentifizierten Opt-out.
• Nicht-Loopback-Einzelbenutzer- und Mehrbenutzer-Bindungen erfordern standardmäßig HARNESS_MCP_AUTH_TOKEN. Um trotzdem nicht authentifiziert auf einer Nicht-Loopback-Schnittstelle auszuführen, setzen Sie HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true explizit.
• POST /mcp ohne mcp-session-id muss eine initialize-Anfrage sein.
• POST /mcp, GET /mcp und DELETE /mcp für bestehende Sitzungen erfordern den mcp-session-id-Header.
• GET /mcp wird für SSE-Benachrichtigungen verwendet (Fortschrittsaktualisierungen und Elicitation-Prompts).
• Leerlaufsitzungen werden nach MCP_SESSION_TTL_MS Millisekunden beendet, sobald keine Anfrage oder kein SSE-Stream aktiv ist (Standard 1800000 oder 30 Minuten).
• GET /health ist der einzige Nicht-MCP-Endpunkt.
• Die Anfragekörpergröße ist durch HARNESS_MAX_BODY_SIZE_MB begrenzt (Standard 10 MB).
• Setzen Sie x-harness-pipeline-version: 0 oder 1 auf der initialize-Anfrage, 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 auf der initialize-Anfrage, um einen strengeren pro-Sitzung-Auto-Approval-Schwellenwert zu wählen. Der Server begrenzt diesen Wert auf die Bereitstellungsebene HARNESS_AUTO_APPROVE_RISK, sodass eine Sitzung die konfigurierte Genehmigungsobergrenze reduzieren, aber nicht erweitern kann.

HarnessID-OAuth-Modus

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

HARNESS_MCP_MODE=oauth

Dies standardmäßig auf den Issuer https://id.harness.io/idp/realms/HarnessIDP, die Ressource https://mcp.harness.io/mcp, den OAuth-Client mcp-client und die Harness-API-Basis https://mcp.harness.io/cli. Überschreiben Sie diese 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 standardmäßig auf <issuer>/protocol/openid-connect/certs, und HARNESS_ACCOUNT_ID ist unnötig, da das Konto aus dem Token stammt.

Der Server veröffentlicht RFC-9728-Metadaten für geschützte Ressourcen und gibt diese 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"

Er validiert die RS256-Signatur des HarnessID-Zugriffstokens, iss, Ablauf und sub unter Verwendung des konfigurierten JWKS-Endpunkts und prüft, dass das Token an HARNESS_MCP_OAUTH_CLIENT_ID über den azp-Anspruch ausgestellt wurde. HARNESS_MCP_OAUTH_RESOURCE ist die RFC-9728-Kennung für geschützte Ressourcen, die für Discovery und Challenges verwendet wird. Aktuelle HarnessID-Zugriffstokens verwenden aud: account anstelle der MCP-URL, daher wird die Ressource nicht mit aud verglichen.

Die Konten-ID stammt aus dem HARNESS_MCP_OAUTH_ACCOUNT_CLAIM-Anspruch des Tokens (Standard account_id), den der HarnessID-organization-Bereich befüllt. Jede Sitzung speichert das Zugriffstoken des Aufrufers und leitet es als Authorization: Bearer an die Harness-API weiter, sodass Harness-RBAC- und Audit-Aufzeichnungen den angemeldeten Benutzer widerspiegeln und nicht ein gemeinsames PAT. Die Sitzung ist an die sub und das Konto gebunden, mit dem sie erstellt wurde: Eine spätere Anfrage kann ein aktualisiertes Token tragen, aber eines für einen anderen Benutzer oder ein anderes Konto wird 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, entdeckt HARNESS_MCP_OAUTH_ISSUER und verwendet dann die RFC-8414-Metadaten dieses Autorisierungsservers. Wenn der Client keine dynamische Client-Registrierung unterstützt, verwenden Sie die vorregistrierte mcp-client-Client-ID.

Siehe HarnessID-OAuth für einen selbst gehosteten MCP-Server für die QA-Keycloak-Checkliste und Validierungsbefehle.

Mehrbenutzermodus

Setzen Sie HARNESS_MCP_MODE=multi-user für gemeinsame HTTP-Bereitstellungen, bei denen sich jeder Client als anderer Harness-Benutzer authentifiziert. In diesem Modus:

• HARNESS_API_KEY darf nicht in der Serverkonfiguration gesetzt sein – der Server hält keine Harness-Anmeldeinformationen.
• Jede Sitzung muss x-harness-api-key auf der initialize-Anfrage bereitstellen. x-harness-account-id ist nur erforderlich, wenn der API-Schlüssel kein Kontensegment einbettet.
• Sitzungen können auch x-harness-org- und x-harness-project-Header bereitstellen, um den Standardbereich für diese Sitzung festzulegen.
• Der Harness-API-Schlüssel fließt in jeden Harness-API-Aufruf für diese Sitzung, sodass der Audit-Trail in Harness den echten Benutzer widerspiegelt.
• HARNESS_MCP_AUTH_TOKEN ist unabhängig und kann weiterhin als zusätzliches Transportlayer-Gate 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 Host-Header-Validierung für DNS-Rebinding-Schutz, und CORS begrenzt Browser-Ursprünge. Keines davon ist Authentifizierung; verwenden Sie HARNESS_MCP_AUTH_TOKEN oder ein authentifiziertes Gateway/Reverse-Proxy für die Zugriffskontrolle.

Client-Konfiguration

Hinweis: HARNESS_ORG und HARNESS_PROJECT sind optional. Sie legen die Org-ID und Projekt-ID fest, die verwendet werden, wenn nicht pro Tool-Aufruf angegeben. Agenten können Orgs und Projekte dynamisch mit harness_list(resource_type="organization") und harness_list(resource_type="project") entdecken. 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 auch einen gehosteten MCP-Endpunkt für Konten, die den verwalteten Dienst aktiviert haben. Dies ist nützlich, wenn Sie einen gemeinsamen Remote-MCP-Endpunkt wünschen, anstatt npx harness-mcp-v2 auszuführen oder den HTTP-Transport selbst zu hosten.

Wichtig: Die Authentifizierung für gehostetes MCP verwendet Harness Platform OAuth. Sie verwendet nicht HARNESS_API_KEY in der Client-Konfiguration. Die Verfügbarkeit von gehostetem MCP wird pro Harness-Konto konfiguriert. Sie müssen daher mit dem Harness-Support zusammenarbeiten, um die Einstellung zu aktivieren/konfigurieren, bevor Sie sie verwenden.

Der gehostete Endpunkt https://mcp.harness.io/mcp ist ein verwalteter Dienst. Die clientseitige MCP-Konfiguration in Claude, Cursor oder Cowork kann nicht überschreiben, an welche Harness-Umgebung er weitergeleitet wird. Für Harness0 oder eine andere private Harness-SaaS-Umgebung bitten Sie den Harness-Support, gehostetes MCP für diese Umgebung zu aktivieren/konfigurieren, oder führen Sie den lokalen/selbst gehosteten Server aus und setzen Sie HARNESS_BASE_URL auf den Ziel-Harness-Host.

Beispiel für gehostetes MCP:

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

Beispiel mit sowohl gehosteten als auch 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 Client-Prozesses, kein Harness-Authentifizierungsfehler. Der MCP-Server wurde noch nicht gestartet, daher hat die Änderung von HARNESS_API_KEY keine Auswirkung auf spawn npx ENOENT.

GUI-Apps (Cursor, Claude Desktop, Devin Desktop, VS Code) übernehmen nicht immer die PATH Ihrer Shell, sodass sie npx oder node nach einem Konfigurationsneuladen möglicherweise nicht finden können. Beheben Sie dies, indem Sie absolute Pfade verwenden und PATH explizit im env-Block festlegen:

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

Finden Sie Ihre Pfade mit which npx und which node in einem Terminal und stellen Sie dann sicher, dass das Verzeichnis mit node im obigen PATH-Wert enthalten ist. Häufige Speicherorte:

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

Claude Desktop (claude_desktop_config.json)

npx (Null-Installation)

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

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

node (lokale Installation)

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

Setzen Sie dann HARNESS_API_KEY in Ihrer Umgebung oder in der Datei .env.

Cursor (.cursor/mcp.json)

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

{
  "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ühren Sie which npx in einem Terminal aus und verwenden Sie diesen vollständigen Pfad für command; fügen Sie das Verzeichnis von 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ühren Sie which harness-mcp-v2 nach npm install -g harness-mcp-v2 aus und verwenden Sie diesen vollständigen Pfad für command; fügen Sie das Verzeichnis von which node am Anfang von PATH ein.

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

npx (Null-Installation)

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

Verwenden Sie einen lokalen Build aus dem Quellcode?

Ersetzen Sie den Befehl durch den Pfad zu Ihrem 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 kompatibel mit MCP-Gateways – Reverse-Proxys, die zentrale Authentifizierung, Governance, Tool-Routing und Beobachtbarkeit über mehrere MCP-Server hinweg bieten. Da der Server das Standard-MCP-Protokoll mit sowohl stdio- als auch HTTP-Transports implementiert, funktioniert er ohne Codeänderungen hinter jedem MCP-konformen Gateway.

Warum ein Gateway verwenden?

• Zentrale Anmeldeinformationsverwaltung – keine API-Schlüssel in Agent-Konfigurationen
• Governance- und Audit-Protokollierung für alle Tool-Aufrufe über Teams hinweg
• Ein einzelner Endpunkt für Agents statt N Verbindungen zu N MCP-Servern
• Zugriffskontrolle – Beschränkung, welche Teams welche Tools verwenden können

Docker-MCP-Gateway

Registrieren Sie den Server in Ihrer Docker-MCP-Gateway-Konfiguration:

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

Portkey

Fügen Sie den Harness-MCP-Server zu Ihrem Portkey-MCP-Gateway für Unternehmens-Governance, Kostenverfolgung und Multi-LLM-Routing hinzu:

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

LiteLLM

Fügen Sie zu Ihrer LiteLLM-Proxy-Konfiguration 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 mit Envoy AI Gateways MCP-Unterstützung über HTTP-Transport:

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

Konfigurieren Sie dann Envoy so, dass es zu http://localhost:8080/mcp als Upstream-MCP-Backend weiterleitet.

Kong

Verwenden Sie Kongs AI-MCP-Proxy-Plugin, um den Harness-MCP-Server über Ihre 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. Verwenden Sie für stdio-basierte Gateways den Standard-Transport. Starten Sie für HTTP-basierte Gateways den Server mit dem http-Transport und richten Sie das Gateway auf den /mcp-Endpunkt.

Docker

Erstellen und führen Sie den Server als Docker-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 mit einem integrierten Health-Check.

Kubernetes

Stellen Sie in einem Kubernetes-Cluster mithilfe der bereitgestellten Manifeste 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 führt 2 Replikate mit Readiness-/Liveness-Probes, Ressourcenlimits und nicht-root-Sicherheitskontext aus. Der Dienst macht Port 80 intern verfügbar (Zielcontainer-Port 3000).

Konfiguration

Der Server lädt automatisch Umgebungsvariablen aus einer .env-Datei im Projektstammverzeichnis, falls eine vorhanden ist. Kopieren Sie .env.example nach .env und füllen Sie Ihre Werte aus. Umgebungsvariablen können auch über Ihre Shell oder die MCP-Client-Konfiguration festgelegt werden.

Variable	Erforderlich	Standard	Beschreibung
HARNESS_MCP_MODE	Nein	single-user	Bereitstellungsmodus: single-user (gemeinsamer API-Schlüssel), multi-user (HTTP mit API-Schlüsseln pro Sitzung) oder oauth (HTTP mit HarnessID-Zugriffstoken-Validierung)
HARNESS_API_KEY	Ja*	--	Harness persönliches Zugriffstoken oder Dienstkonto-Token. Erforderlich im single-user-Modus. Darf NICHT im multi-user- oder oauth-Modus gesetzt werden, wo jede Sitzung ihre eigene Anmeldeinformation mitbringt
HARNESS_ACCOUNT_ID	Nein	(aus PAT/SAT)	Harness-Kontoidentifikator. Wird im Einzelbenutzermodus automatisch aus PAT/SAT-Tokens extrahiert; Mehrbenutzersitzungen können ihren eigenen über x-harness-account-id bereitstellen, wenn der API-Schlüssel keinen eingebetteten enthält
HARNESS_BASE_URL	Nein	https://app.harness.io (https://mcp.harness.io/cli im OAuth-Modus)	Harness-API/UI-Basis-URL. Der OAuth-Modus leitet standardmäßig über den gehosteten MCP /cli-Proxy; andere Modi verwenden die Harness-SaaS-API direkt
HARNESS_MCP_OAUTH_ISSUER	Nein	https://id.harness.io/idp/realms/HarnessIDP	HarnessID-Aussteller, der exakt gegen den iss-Anspruch des Zugriffstokens abgeglichen wird
HARNESS_MCP_OAUTH_RESOURCE	Nein	https://mcp.harness.io/mcp	Öffentliche kanonische MCP-URL, veröffentlicht als RFC-9728-Ressourcenkennung
HARNESS_MCP_OAUTH_JWKS_URI	Nein	<issuer>/protocol/openid-connect/certs	HarnessID-JWKS-Endpunkt, der zur Validierung von RS256-Zugriffstoken-Signaturen verwendet wird
HARNESS_MCP_OAUTH_CLIENT_ID	Nein	mcp-client	HarnessID-Client, für den das Zugriffstoken ausgestellt sein muss, geprüft gegen den azp-Anspruch des Tokens
HARNESS_MCP_OAUTH_ACCOUNT_CLAIM	Nein	account_id	Zugriffstoken-Anspruch, der die Harness-Konto-ID trägt, befüllt durch den HarnessID-organization-Bereich
HARNESS_MCP_OAUTH_SCOPES	Nein	openid profile email organization	Durch Leerzeichen getrennte Bereiche, die in den RFC-9728-Metadaten für geschützte Ressourcen beworben werden
HARNESS_FME_API_KEY	Nein	--	Optionale Einzelbenutzer-/selbstgehostete FME/Split-Admin-Anmeldeinformation, die für fme_-Ressourcen nur im Legacy-Modus (workspace_id) verwendet wird. Legacy-FME ist im OAuth-Modus nicht verfügbar, daher werden HarnessID-Tokens nie an api.split.io gesendet; verwenden Sie stattdessen den Harness-nativen org_id+project_id-Bereich. Darf nicht im multi-user- oder oauth-Modus gesetzt werden
HARNESS_FME_BASE_URL	Nein	https://api.split.io	Split/FME-Admin-API-Basis-URL, die von fme_-Ressourcen nur im Legacy-Modus (workspace_id) verwendet wird. HTTP-URLs erfordern HARNESS_ALLOW_HTTP=true für die lokale Entwicklung. Der Harness-native (org_id+project_id)-Modus ignoriert dies und verwendet stattdessen den Standard-HARNESS_API_KEY/HARNESS_BASE_URL
HARNESS_ORG	Nein	--	Organisations-ID. Wird verwendet, wenn org_id nicht pro Tool-Aufruf angegeben ist. Wenn weggelassen, muss org_id explizit bereitgestellt werden. Agenten können Organisationen auch dynamisch über harness_list(resource_type="organization") entdecken
HARNESS_PROJECT	Nein	--	Projekt-ID. Wird verwendet, wenn project_id nicht pro Tool-Aufruf angegeben ist. Agenten können Projekte auch dynamisch über harness_list(resource_type="project") entdecken
HARNESS_API_TIMEOUT_MS	Nein	30000	HTTP-Request-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 HTTP-Request-Body-Größe in MB für den http-Transport
HARNESS_RATE_LIMIT_RPS	Nein	10	Clientseitige Request-Drosselung (Requests pro Sekunde) für Harness-APIs
LOG_LEVEL	Nein	info	Log-Ausführlichkeit: debug, info, warn, error
HARNESS_TOOLSETS	Nein	(Standardwerte)	Kommagetrennte Toolset-Liste. Leer lädt Standard-Toolsets. Unterstützt +name, um Opt-in-Toolsets explizit einzuschließen, und -name, um Standardwerte zu entfernen (siehe Toolset-Filterung)
HARNESS_READ_ONLY	Nein	false	Blockiert alle ändernden Operationen (Erstellen, Aktualisieren, Löschen, Ausführen). Nur Liste und Abruf sind erlaubt. Nützlich für gemeinsame/Demo-Umgebungen
HARNESS_AUTO_APPROVE_RISK	Nein	none	Risikobasierte Auto-Genehmigungsschwelle für autonome Workflows. Operationen auf oder unter diesem Risiko laufen ohne Bestätigung. Werte: none, low_write, medium_write, high_write, all. Siehe Elicitation
HARNESS_SKIP_ELICITATION	Nein	false	Veraltet — verwenden Sie stattdessen HARNESS_AUTO_APPROVE_RISK=all. Aus Gründen der Abwärtskompatibilität beibehalten
HARNESS_ALLOW_HTTP	Nein	false	Erlaubt Nicht-HTTPS-HARNESS_BASE_URL. Standardmäßig erzwingt der Server HTTPS aus Sicherheitsgründen. Setzen Sie true nur für die lokale Entwicklung gegen eine Nicht-TLS-Harness-Instanz
HARNESS_PIPELINE_VERSION	Nein	0	(Alpha) Pipeline-YAML-Version. 0 lädt den pipeline-Ressourcentyp und schließt pipeline_v1 aus; 1 lädt pipeline_v1 und schließt pipeline aus. HTTP-Sitzungen können dies zur Initialisierungszeit mit x-harness-pipeline-version: 0 oder 1 überschreiben
HARNESS_MCP_ALLOWED_HOSTS	Nein	--	Kommagetrennte Hostnamen, die von der HTTP-Transport-Host-Header-Validierung erlaubt sind. mcp.harness.io ist standardmäßig für Localhost-Bindungen erlaubt; fügen Sie hier Proxy-/benutzerdefinierte Domänen hinzu
HARNESS_MCP_AUTH_TOKEN	Nein	--	Statisches Bearer-Token, das auf /mcp-HTTP-Routen erforderlich ist, wenn gesetzt. Standardmäßig für Nicht-Loopback-Einzelbenutzer- und Mehrbenutzer-Bindungen erforderlich. Muss im oauth-Modus nicht gesetzt sein
HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP	Nein	false	Erlaubt explizit unauthentifizierten HTTP-Transport auf Nicht-Loopback-Bindungen. Nur hinter einer anderen authentifizierten Kontrolle verwenden
HARNESS_MCP_TRUST_PROXY	Nein	0	Anzahl der Reverse-Proxy-/Load-Balancer-Hops, die für die Client-IP-Auflösung vertraut werden (Express trust proxy). Setzen Sie dies auf die Anzahl der Proxys vor dem Server, damit die Pro-IP-Ratenbegrenzung auf den echten Client und nicht auf den Proxy-Socket-Peer angewendet wird
HARNESS_MCP_LOG_FILE	Nein	~/.claude/harness-mcp.log	Datei, die für stdio-Trennungs-/Absturzdiagnosen verwendet wird, 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 an eine zeilenweise getrennte JSON-Datei anhängen, für dauerhafte lokale Sammlung
HARNESS_AUDIT_WEBHOOK_URL	Nein	--	HTTPS-Endpunkt, der gebündelte Audit-Ereignisse empfängt. HTTP-URLs erfordern HARNESS_ALLOW_HTTP=true für die lokale Entwicklung
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 Webhook-Flush gebündelt werden
HARNESS_AUDIT_WEBHOOK_FLUSH_MS	Nein	5000	Maximale Zeit, um Audit-Ereignisse vor dem Webhook-Flush zu halten
OTEL_EXPORTER_OTLP_ENDPOINT	Nein	--	Aktiviert OpenTelemetry-Audit-Spans, wenn die optionalen OpenTelemetry-Pakete installiert sind
HARNESS_SEARCH_PROVIDER	Nein	local	Semantischer Such-Backend: local (In-Process-ONNX-Embeddings, Standard), remote (externer Suchdienst über HTTP, erforderlich für den Mehrbenutzermodus) oder none (semantische Suche deaktivieren, Rückfall auf reine Keyword-Streuung). Verwenden Sie none in luftdichten Umgebungen oder wenn das Laden des Startmodells unerwünscht ist
HARNESS_SEARCH_SERVICE_URL	Nein	--	Basis-URL des entfernten Suchdienstes, wenn HARNESS_SEARCH_PROVIDER=remote (z. B. http://search-svc:8080). Erforderlich bei Verwendung des remote-Anbieters
HARNESS_SEARCH_SERVICE_HEADERS	Nein	--	JSON-Objekt mit Headern, die mit jeder Anfrage an den entfernten Suchdienst gesendet werden. Unterstützt jedes Authentifizierungsschema: {"Authorization":"Bearer tok"}, {"x-api-key":"key"} oder mehrere interne Dienst-zu-Dienst-Header
HARNESS_HF_CACHE_DIR	Nein	/tmp/hf-cache	Verzeichnis für den @huggingface/transformers-Modellcache, der vom local-Suchanbieter verwendet wird. Das Docker-Image backt das Modell in /app/.cache/hf ein, um Laufzeit-Downloads zu vermeiden. In Produktionsumgebungen auf einen persistenten Volume-Pfad setzen
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	Nein	3	Maximale gleichzeitige Log-Blob-Downloads, die von harness_diagnose beim Abrufen von Logs für fehlgeschlagene Schritte ausgelöst werden. Nur erhöhen, wenn die Diagnose-Latenz von der Log-Abruf-Wanduhrzeit dominiert wird und der Pod Speicherreserven hat

Semantische Suche

harness_search verwendet semantisches Routing, um Scatter-Gather-API-Aufrufe einzugrenzen, bevor sie an Harness weitergeleitet werden. Drei Suchanbieter sind verfügbar:

Anbieter	Verwendungszweck
local (Standard)	Einzelbenutzer- stdio-Modus. Führt all-MiniLM-L6-v2 prozessintern über @huggingface/transformers aus. Lädt beim ersten Gebrauch ein ~23 MB großes Modell herunter; nachfolgende Starts verwenden den Cache.
remote	Mehrbenutzer-HTTP-Modus (von Harness gehostet). Delegiert Einbettung und Abruf an einen externen Suchdienst. Mandantenisolierung wird über tenant_id erzwungen – statisches Wissen/Dokumentation verwendet global, pro-Konto-Entitätsdaten verwenden die Konto-ID.
none	Deaktiviert die semantische Suche vollständig; fällt auf Keyword-Scatter-Gather über alle Ressourcentypen zurück.

Konfiguration des entfernten 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

Testen des entfernten Anbieters lokal 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 /v1/health-, /v1/ingest- und /v1/search-Vertrag wie der Produktionssuchdienst. Er verwendet eine einfache Bag-of-Chars-Einbettung, sodass kein Modell-Download erforderlich ist – die Ergebnisse sind semantisch plausibel, aber nicht produktionsreif.

HTTPS-Erzwingung

HARNESS_BASE_URL muss standardmäßig HTTPS verwenden. Wenn Sie eine Nicht-HTTPS-URL festlegen (z. B. http://localhost:8080), weigert sich der Server zu starten mit:

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 weitergeleiteten Harness-API-Operationen (list, get, create, update, delete und execute) erzeugen strukturierte Audit-Ereignisse, wenn Audit-Sinks konfiguriert sind. Verändernde Ereignisse enthalten den Bestätigungspfad, der von Elicitation oder Auto-Approval verwendet wird, wenn ein Bestätigungskontext vorhanden ist; Leseereignisse lassen derzeit Bestätigungsmetadaten aus. Lokale Metadaten- und Schema-Erkennungswerkzeuge, die die Registry umgehen, wie harness_describe und harness_schema, sind nicht Teil dieses Audit-Streams. Eine stderr-Sink ist standardmäßig registriert, läuft jedoch über den normalen Logger und gehorcht LOG_LEVEL; konfigurieren Sie Datei- oder Webhook-Sinks für dauerhafte Audit-Erfassung:

• HARNESS_AUDIT_FILE hängt zeilenumbruchgetrennte JSON-Ereignisse für die lokale Erfassung an.
• HARNESS_AUDIT_WEBHOOK_URL sendet { "events": [...] }-Stapel an einen HTTPS-Webhook, optional mit HARNESS_AUDIT_WEBHOOK_TOKEN. Fehlgeschlagene Stapel werden mit begrenzter Kapazität erneut in die Warteschlange gestellt und schließlich mit einer Warnung verworfen, anstatt die Tool-Ausführung zu blockieren.
• OTEL_EXPORTER_OTLP_ENDPOINT aktiviert Audit-Spans, wenn die optionalen OpenTelemetry-Peer-Abhängigkeiten installiert sind. Die Sink verwendet einen vorhandenen Tracer-Provider, wenn einer registriert ist, andernfalls bootstrappt sie einen eigenständigen OTLP-Exporter.

Jedes Ereignis enthält den Tool-Namen, den Ressourcentyp, die Operation, Kennungen, Zeitstempel, Risiko, Ergebnis, HTTP-Methode/Pfad, Dauer und die Bestätigungsmethode, sofern zutreffend. Audit-Sinks sind Best-Effort-Telemetrie; Zustellungsprobleme werden protokolliert und nie wiedergegeben oder die zugrunde liegende Harness-API-Operation geändert. Für OTel-Einrichtungsdetails und Span-Attribute siehe specs/005-otel-audit-sink.md.

Tools-Referenz

Der Server stellt 11 MCP-Tools bereit. Die meisten API-Tools akzeptieren org_id und project_id als optionale Überschreibungen – wenn sie weggelassen werden, fallen sie auf HARNESS_ORG und HARNESS_PROJECT zurück. harness_describe ist nur lokale Metadaten und verwendet keinen Org-/Projekt-Bereich.

URL-Unterstützung: Die meisten API-orientierten Tools akzeptieren einen url-Parameter – 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 kein url.

Bereichsunterstützung: Ressourcentypen mit Konto-/Org-/Projekt-Varianten legen supportedScopes in harness_describe offen. Ü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 Projektkennungen.

Aktuelle Multi-Bereich-Ressourcen umfassen connector, service, environment, infrastructure, secret, file_store, template, policy und policy_set. Wenn resource_scope weggelassen wird, verwendet die Registry den Standardbereich der Ressource und die konfigurierten Standardwerte, außer Ressourcen, die als optionaler Bereich markiert sind, können Org/Projekt weglassen, sofern nicht explizit übergeben. Harness-URLs können den Bereich auch automatisch festlegen, wenn der Pfad Konto- oder Projektebene-Kontext enthält.

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

Tool	Beschreibung
harness_describe	Verfügbare Ressourcentypen, Operationen und Felder entdecken. Kein API-Aufruf – gibt lokale Registry-Metadaten zurück.
harness_schema	Exakte YAML/JSON-Schema-Definitionen und Beispiele zum Erstellen/Aktualisieren von Ressourcen abrufen. Pipeline-/Template-Schemas sind gebündelt; Connector-, Umgebungs-, Service-, Secret- und Infrastruktur-Schemas sind kontextabhängige Entitäts-Schemas, 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 tiefes Eintauchen ü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- (Git-basierte) Pipelines. Fragt nach Benutzerbestätigung über Elicitation.
harness_update	Eine vorhandene Ressource aktualisieren. Unterstützt Inline- und Remote- (Git-basierte) Pipelines. Fragt nach Benutzerbestätigung über Elicitation.
harness_delete	Eine Ressource löschen. Fragt nach Benutzerbestätigung über Elicitation. Destruktiv.
harness_execute	Eine Aktion auf einer Ressource ausführen (Pipeline ausführen/erneut ausführen, Pipeline aus Git importieren, Flag umschalten, App synchronisieren). Fragt nach Benutzerbestätigung über Elicitation. Für Pipeline-Ausführungen den unten beschriebenen Runtime-Input-Workflow verwenden (unterstützt branch/tag/pr_number/commit_sha-Kurzschreibweise-Erweiterung).
harness_search	Mit einer einzigen Abfrage über Harness-Ressourcentypen suchen. Verwendet semantisches Routing (lokale all-MiniLM-L6-v2 ONNX-Embeddings, 384-dimensional), um relevante Ressourcentypen aus einem knowledge-Korpus vorherzusagen, der beim Start indiziert wird – typischerweise von ~163 Typen auf 1–8 eingegrenzt, bevor Scatter-Gather erfolgt. Fällt auf vollständiges Keyword-Scatter-Gather zurück, wenn die semantische Konfidenz niedrig ist. Die Antwort enthält semantic_routed und types_skipped, wenn Routing ausgelöst wird. Siehe docs/search-guidelines.md für Informationen, 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-Timing und Fehlerdetails zurückgegeben; für Connectors/Delegates/GitOps-Apps werden gezielte Health- und Troubleshooting-Signale zurückgegeben.
harness_status	Ein Echtzeit-Projekt-Health-Dashboard abrufen – aktuelle Ausführungen, Fehlerraten und Deep Links.

Schema-Lookup-Workflow

Verwenden Sie harness_schema, bevor Sie YAML-basierte Ressourcen erstellen oder aktualisieren, damit Agenten exakte Feldnamen und Einschränkungen kopieren können, anstatt aus Prosa zu raten.

• Gebündelte Schemas umfassen pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1 und agent-pipeline.
• Entitäts-Schemas umfassen connector, environment, service, secret und infrastructure. Sie sind kontextabhängig (account, org oder project) und erfordern org_id/project_id, wenn der ausgewählte Kontext dies erfordert.
• Release-Management-Definitionen (release_process, release_activity) rufen live JSON-Schemas von RMG /api/yamlSchema ab (nicht gebündelt). Übergeben Sie scope, org_id und project_id, wenn Sie auf Organisation oder Projekt eingrenzen.
• Gebündelte Entitäts-Snapshots werden zuerst verwendet, wenn sie mit dem Laufzeitkonto übereinstimmen; andernfalls fällt das Tool auf die Harness NG /yaml-schema-API zurück und speichert das Ergebnis zwischen.
• Lassen Sie path für eine Feld-/Abschnittsübersicht weg, übergeben Sie dann einen punktgetrennten path, um eine verschachtelte Definition zu inspizieren.

Beispiele:

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

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

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

Tool-Beispiele

Entdecken, welche Ressourcen verfügbar sind:

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

Über alle Ressourcentypen suchen:

{ "query": "payment-service" }

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

{ "execution_id": "abc123XYZ" }

Von einer Harness-URL aus 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-Health 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 fehlgeschlagenen Step-Logs:

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

Zusammenfassungsmodus mit aktivierten Logs (das Beste aus beiden Welten):

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

Projekt-Health-Status 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" }

Das aufgelöste LLM-Authoring-Pipeline 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 Schema-Instanz 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ührungs-Workflow (Empfohlen)

Für v0-Pipelines diese Reihenfolge verwenden, um Eingabefehler zur Laufzeit zu reduzieren:

1. Erforderliche Runtime-Inputs entdecken

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

2. Eingabestrategie wählen

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

• Komplexe/strukturelle Eingaben: input_set_ids verwenden (CI-Codebase-/Build-Blöcke und verschachtelte Vorlageneingaben werden so am besten behandelt).

• CI-Codebase-Kurzschlüssel (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 Kurzschreibweise-Erweiterung wird übersprungen, wenn inputs.build bereits vorhanden ist (explizites build gewinnt).

3. Die Ausführung starten

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

• Für Git-basierte Pipelines, deren YAML aus einem nicht standardmäßigen Branch geladen werden soll, params.pipeline_branch übergeben (an Harness als branch gesendet). Dieser explizite Definitions-Selektor hat Vorrang vor dem params.branch-Alias. inputs.branch wählt unabhängig den CI-Codebase-Branch:

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

4. Optional: beides kombinieren

• input_set_ids für die Basisstruktur und inputs für einfache Überschreibungen verwenden.

Für v1-Pipelines:

1. harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>") abrufen. Für Git-basierte Pipelines branch_name, connector_ref und repo_name über params übergeben.
2. Jedes zurückgegebene inputs[].details.name als Top-Level-Schlüssel in harness_execute.inputs verwenden.
3. harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}) ausführen. Der Server umschließt diese Werte unter einer inputs:-YAML-Wurzel und sendet den inputs_yaml-Body der API. Wenn Pflichtfelder nicht aufgelöst sind, gibt das Tool einen Pre-Flight-Fehler mit den erwarteten Schlüsseln und vorgeschlagenen Eingabesätzen zurück. Sie können verfügbare Kurzform-Zuordnungen mit harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands) einsehen.

Dynamische Pipeline-Ausführung

Verwenden Sie pipeline_dynamic_execution.run, wenn ein Agent oder ein externes System das vollständige v0-Pipeline-YAML zur Laufzeit generiert und es gegen eine bestehende Harness-Pipeline-Shell ausführen muss. Dies ist kein Ersatz für normale pipeline.run: Die gespeicherte v0-Pipeline muss bereits existieren, Dynamische Ausführung zulassen muss auf Konto- und Pipeline-Ebene aktiviert sein, und der Aufrufer benötigt Bearbeitungs- und Ausführungsberechtigungen 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 yaml-Feld sein. Rohe Zeichenfolgentexte werden vom öffentlichen harness_execute-Schema abgelehnt.
• body.yaml kann ein YAML-String oder ein JSON-Pipeline-Objekt sein; JSON wird vor der Anfrage in YAML serialisiert.
• Laufzeit-<+input>-Platzhalter werden von dieser API nicht aufgelöst. Reichen Sie vollständig aufgelöstes YAML ein.
• Eingabesätze, selektive Stufenausführung, Wiederholung und Trigger werden vom Endpunkt für dynamische Ausführung nicht unterstützt.
• Die Aktion ist high_write und verwendet den normalen Bestätigungs-/Auto-Approval-Pfad. Die Antwort projiziert die API-Hülle auf { "execution_id": "...", "status": "..." } und enthält einen openInHarness-Ausführungslink, wenn Bereichsdaten verfügbar sind.

Wenn Harness die Ausführung als nicht aktiviert ablehnt, überprüfen Sie sowohl die Einstellung „Dynamische Ausführung zulassen" auf Kontoebene als auch den Umschalter auf Pipeline-Ebene unter Pipeline -> Erweiterte Optionen -> Einstellungen für dynamische Ausführung.

Forensik der Ausführungseingaben

Verwenden Sie execution_inputs nach einer Ausführung, um das zusammengeführte Eingabe-YAML zu überprüfen, das eine bestimmte Ausführung erzeugt hat. Dies ist nützlich, wenn ein Fehler von der Zusammenführung von Eingabesätzen, Git-gestützten Eingabesatz-Zweigen oder Trigger-/Laufzeitwerten abhängt, die sich von der Ausführungsseite allein 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 projiziert auf:

• executionId – die Planausführungs-ID von resource_id.
• inputSetYaml – zusammengeführtes Laufzeit-Eingabe-YAML, das für die Ausführung verwendet wurde, oder null.
• inputSetTemplateYaml – Eingabevorlage zum Zeitpunkt der Ausführung, oder null.
• resolvedYaml – ausdrucksaufgelöstes YAML, wenn resolve_expressions=true, andernfalls normalerweise null.
• inputSetDetails – beitragende gespeicherte Eingabesätze als { identifier, name }-Paare.
• inputSetBranchName – Quellzweig für Git-gestützte Eingabesätze, oder null.

execution_inputs ist nur für Get und mit Leserisiko. Wenn resolve_expressions weggelassen wird, lässt der Server die API-Abfrageparameter weg und Harness verwendet seinen Standardmodus für die UNKNOWN-Auflösung.

Wartemodus für Pipeline-Ausführung

Für pipeline.run, pipeline.retry und pipeline_v1.run übergeben Sie wait: true, damit der Server abfragt, bis die Ausführung einen Endstatus erreicht. Dadurch bleiben Pipeline-Start und Statusprüfung in einem einzigen Tool-Aufruf, anstatt den Client oder das LLM zu bitten, eine Abfrageschleife auszuführen.

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

• Standard-Timeout beträgt 600 Sekunden; zulässiger Bereich ist 10 Sekunden bis 7200 Sekunden.
• Das anfängliche Abfrageintervall beträgt standardmäßig 3 Sekunden, wird um den Faktor 1,5 zurückgefahren und ist bei 30 Sekunden gedeckelt.
• 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 weiterhin 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, es sei denn, Sie haben bestätigt, dass die erste Ausführung nicht läuft.
• Fehlgeschlagene Endstatus enthalten _diagnose_hint, das auf harness_diagnose(resource_type="execution", options={execution_id: "..."}) verweist.

Bitten Sie den AI-DevOps-Agenten, eine Pipeline zu erstellen:

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

Aktualisieren Sie einen Dienst über natürliche Sprache:

{
  "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 in Harness gespeichert	Standard. Einfachste Einrichtung, kein Git erforderlich.
Remote (externes Git)	Pipeline-YAML in GitHub, GitLab, Bitbucket usw. gespeichert.	Teams, die Git-gestütztes Pipeline-as-Code mit einem externen Anbieter verwenden.
Remote (Harness Code)	Pipeline-YAML in einem Harness-Code-Repository gespeichert	Teams, die das integrierte Git-Hosting von Harness verwenden.

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

Remote-Pipeline erstellen (externes 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"
  }
}

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

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

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

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

Connector erstellen:

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

Trigger löschen:

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

Eingabesätze für eine Pipeline auflisten:

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

Bestimmten Eingabesatz abrufen:

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

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

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

Eingabesatz löschen:

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

Ressourcentypen

255 Ressourcentypen, organisiert in 41 Toolsets. Jeder Ressourcentyp unterstützt eine Teilmenge von CRUD-Operationen und optionale Ausführungsaktionen.

Plattform

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
organization	x	x	x	x	x
project	x	x	x	x	x

Pipelines

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
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-x-harness-pipeline-version-Initialisierungsheader wählen die Standardversionspräferenz; sie blenden die andere Version nicht aus.

KI-Agenten

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
agent	x	x	x	x	x
agent_run	x

Dienste

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
service	x	x	x	x	x

Umgebungen

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
environment	x	x	x	x	x	move_configs

Connectors

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
connector	x	x	x	x	x	test_connection
connector_catalogue	x

Infrastruktur

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
infrastructure	x	x	x	x	x	move_configs

Geheimnisse

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
secret	x	x

Ausführungsprotokolle

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
execution_log		x

Prüfpfad

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
audit_event	x	x

Delegaten

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
delegate	x	x
delegate_token	x	x	x		x	revoke, get_delegates

Code-Repositorys

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
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 commit-Erstellung überträgt eine oder mehrere Dateiaktionen direkt über die Harness-Code-API ohne Klonen. Übergeben Sie body.title, body.branch und body.actions; jede Aktion ist CREATE, UPDATE, DELETE oder MOVE, und UPDATE erfordert den aktuellen Blob-SHA.

Die file_content-Liste gibt jeden Pfad an einer Referenz zurück; Abrufen gibt Datei- oder Verzeichnisinhalt zurück (lassen Sie path weg oder übergeben Sie es leer für das Repository-Stammverzeichnis; verschachtelte Pfade behalten Schrägstriche). Lassen Sie git_ref weg, um den Standardzweig des Repositorys zu verwenden – raten Sie nicht main.

Artefakt-Registries

| 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-Dateispeicher-Dateien und -Ordner über die generischen Tools. Es unterstützt Konto-, Organisations- und Projektbereich; übergeben Sie resource_scope="account"|"org"|"project" oder fügen Sie eine Harness-Dateispeicher-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"})

Multipart-Body-Einschränkungen:

• Erstellen/Aktualisieren akzeptiert JSON body, konvertiert es dann in multipart/form-data für /ng/api/file-store.
• name, type (FILE oder FOLDER) und parent_identifier sind erforderlich; verwenden Sie das Literal "Root" nur für das Stammverzeichnis des ausgewählten Bereichs.
• FILE Erstellen erfordert genau eines von content (UTF-8-Zeichenfolge) oder content_base64 (gültiges, nicht leeres Base64). FILE Aktualisieren kann Inhalt für reine Metadaten-Updates weglassen oder genau ein Inhaltsfeld bereitstellen, um Inhalt zu ersetzen.
• FOLDER Erstellen/Aktualisieren muss content und content_base64 weglassen.
• Optionales file_usage muss MANIFEST_FILE, CONFIG oder SCRIPT sein; optionale skalare Metadaten wie description, mime_type, path und tags müssen Zeichenfolgen sein.
• Upload-Inhalt ist auf 100 MB begrenzt. Bestätigungsaufforderungen schwärzen content, content_base64 und contentBase64-Vorschauen vor der Abfrage.

list_children akzeptiert entweder Kurzform (resource_id plus params.folder_name oder params.file_store_id/params.folder_identifier plus params.folder_name) oder einen vollständigen FileStoreNode body mit identifier, name und type: "FOLDER". Vollständige Bodies verwenden Harness camelCase parentIdentifier; Kurzform kann params.parent_identifier verwenden.

Vorlagen

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

Vorlagenoperationen verwenden die Harness-Vorlagendienstpfade (/template/api/templates...). Erstellen und Aktualisieren erfordern die vollständige Vorlagen-YAML-Zeichenfolge in body.template_yaml oder body.yaml; version_label zielt auf eine bestimmte Version für Aktualisieren/Löschen ab, während Löschen ohne version_label alle Versionen lö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 projektbezogen. Beginnen Sie mit iacm_workspace, um Workspace-Identifikatoren 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 Konto-, Organisations- oder Projektebene. Die Provider-Registry ist kontobezogen.

iacm_module erstreckt sich über Konto-, Organisations- und Projektbereich. Es verwendet standardmäßig die Konto-Registry; jede Operation (Auflisten, Abrufen, Erstellen, Aktualisieren) sendet dieselben scope_org / scope_project-Abfrageparameter, sodass ein von Ihnen erstelltes Modul im Bereich auffindbar ist, in dem Sie es erstellt haben. Wählen Sie den Bereich mit resource_scope="account" | "org" | "project" plus org_id/project_id. Die Bereichsfestlegung ist optional: Wenn resource_scope weggelassen wird, gelten org_id/project_id nur, wenn Sie sie explizit übergeben — konfigurierte HARNESS_ORG/HARNESS_PROJECT-Standardwerte werden nicht angewendet, sodass eine Umgebungsprojektkonfiguration nicht stillschweigend ein Konto-Modul unter einem Projekt registrieren kann. Die eigenen org/project-Felder eines Modul-Bodys lokalisieren dessen Git-Connector und stehen in keinem Zusammenhang mit diesem Sichtbarkeitsbereich.

iacm_workspace Erstellen/Aktualisieren gibt nur { policy_evaluation } zurück — folgen Sie mit harness_get, um den Workspace abzurufen. iacm_variable_set und iacm_module Erstellen/Aktualisieren geben die Ressource selbst zurück. iacm_provider Erstellen gibt nur { id } zurück — folgen Sie mit harness_get; Aktualisieren ist nur versionsorientiert (POST/PUT /providers/{id}/version) — es gibt kein Metadaten-PUT. Versionsschreibvorgänge können einen leeren Body zurückgeben; HarnessClient normalisiert dies zu { status: "SUCCESS", message: "No content" }.

Variablensatz-Aktualisieren ist HTTP-PUT mit vollständigen Ersetzungssammlungen — immer zuerst harness_get, dann PUT des vollständigen gewünschten Bodys (terraform_variables / environment_variables sind bei Aktualisierung erforderlich; weglassen/leer löscht Connectors und Variablendateien). Modul-Aktualisieren ist ebenfalls PUT — bevorzugen Sie Get-then-Put für optionale Felder. Schreibvorgänge sind medium_write und erfordern Bestätigung (Abfrage oder confirm: true).

Variablensatz- und Provider-Registry-RBAC (iac_variableset_*, iac_providerregistry_*) sind derzeit experimentell in Harness — Zugriffsprüfungen erlauben immer, bis iac-server die Durchsetzung aktiviert. Modul-Registry-RBAC (iac_registry_view / iac_registry_edit) ist aktiv und durchsetzbar. MCP leitet das PAT/SAT des Aufrufers immer 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 Arbeitsablauf:

1. harness_list(resource_type="iacm_workspace", org_id="...", project_id="..."), um den Workspace zu finden.
2. harness_create / harness_update auf iacm_workspace, um von Grund auf oder aus einer Vorlage zu erstellen (associated_template) oder einen vorhandenen Workspace zu aktualisieren — Antwort ist 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 auf iacm_variable_set (optional mit resource_scope) für wiederverwendbare Terraform/Umgebungsvariablensätze — Antwort ist die VariableSet-Ressource.
5. harness_list / harness_create / harness_update auf iacm_module für die Modul-Registry (name + system erforderlich; fügen Sie resource_scope mit org_id/project_id für ein organisations- oder projektbezogenes Modul hinzu) — Antwort ist die Modulressource.
6. harness_list / harness_create / harness_update auf iacm_provider für die Konto-Provider-Registry (body.type für Erstellen erforderlich; Erstellen gibt nur { id } zurück — dann harness_get; Aktualisieren erstellt/aktualisiert nur Versionen) — Versionsaktualisierung kann leeren Erfolg zurückgeben.
7. harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="..."), um Terraform-Ressourcen, Ausgaben und Datenquellen zu überprü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 Vorher/Nachher-Ressourcenunterschiede für eine Plan-, Apply- oder Destroy-Aktivität zu überprüfen.

IaCM-Listenantworten zeigen page_count als Anzahl nur für die aktuelle Seite (außer iacm_variable_set, das nicht paginiert ist). Wenn has_more wahr ist, fordern Sie weiterhin die nächste 1-basierte Seite an und summieren Sie Seitenzahlen, wenn Sie eine Gesamtsumme 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
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 auch body.state (open oder closed) und leitet Statusänderungen an den dedizierten Harness-Code-PR-Statusendpunkt weiter; senden Sie Titel/Beschreibungsbearbeitungen in einem separaten Aktualisierungsaufruf.

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

Release-Management

Release-Management-Ressourcen (RMG) sind standardmäßig aktiviert. Definitionsressourcen (release_process, release_activity) unterstützen Auflisten/Abrufen/Erstellen/Aktualisieren/Löschen mit body.yaml; rufen Sie harness_schema(resource_type="release_process"|"release_activity") vor Erstellen/Aktualisieren auf. Ausführungsressourcen überwachen laufende Releases — die meisten Listenoperationen erfordern release_id (UUID aus harness_list resource_type=release oder den UI-URL-Slug wie 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 Kontobereichsfestlegung über den Harness-Account-Header. Organisations-/Projektbereich verwendet headerbasierte Bereichsfestlegung, wenn org_id/project_id bereitgestellt werden. release_execution_phase ist nur zum Auflisten — verwenden Sie das identifier-Feld jedes Phasenelements als params.phase_identifier, wenn Sie harness_get auf Phasen-Eingabe-/Ausgaberessourcen aufrufen (rufen Sie harness_get nicht auf release_execution_phase selbst auf). Release-Listen-status-Filterung wird clientseitig nur auf der aktuellen Seite angewendet; paginieren Sie mit denselben Filtern weiter, wenn Ergebnisse mehrere Seiten umfassen können.

Ressourcentyp	Liste	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 Arbeitsablauf:

1. harness_list(resource_type="release_process", org_id="...", project_id="..."), um Orchestrierungsprozessdefinitionen zu entdecken.
2. harness_schema(resource_type="release_process") (oder release_activity) vor dem Erstellen/Aktualisieren; dann harness_create / harness_update mit body.yaml.
3. harness_list(resource_type="release", org_id="...", project_id="..."), um aktive oder aktuelle Releases zu finden (Standard-Rückblick von 30 Tagen; optional filters.status, filters.search_term, filters.days_back).
4. harness_get(resource_type="release", release_id="...") für Releasedetails.
5. harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) für Phasenstatus; dasselbe release_id für release_execution_task und release_execution_activity.
6. harness_get auf release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_output oder release_execution_activity_input mit release_id plus params.phase_identifier / params.activity_identifier / activity_execution_id, wie auf jeder Ressource dokumentiert.

Vibe

Das standardmäßig aktivierte vibe-Toolset deckt den Vibe Orchestrator BFF-Vertrag unter ${HARNESS_BASE_URL}/vibe/v1 ab. Es verwendet die bestehende Harness-Verbindung und den Kontokopf, ohne Konto-/Org-/Projektabfrageparameter oder Bereichsfelder zu Anfragetexten hinzuzufügen. Das Team validierte den Vibe-Ablauf mit Harness-API-Key-Authentifizierung (PAT/SAT), sodass keine Opt-in-Einstellung für Standardsitzungen erforderlich ist. Die kuratierten OpenAPI-Dokumente tragen Bearer-/Sitzungsauthentifizierung; der OAuth-Modus des Servers leitet das Bearer-Token der aktuellen Sitzung weiter. Automatisierte Regressionen verifizieren beide Header-Pfade; Gateway-Authentifizierung bleibt der Konfiguration der Zielumgebung unterworfen.

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

Die API unterstützt zwei Aufnahmepfade. Behalten Sie diese API-nativen Anforderungsformen bei:

Quelle, die dem Codierungsagenten zur Verfügung steht	API-Ablauf
GitHub-Repository-Link/Connector	harness_create mit resource_type="vibe_project" und body.mode plus die modusspezifischen Felder. Der Vertrag benennt github_link und github_connector, definiert jedoch nicht deren URL-, Branch- oder Connectorfeldformen; diese Felder werden ohne erfundene Zuordnung an das Backend weitergeleitet.
ZIP-Datei	Rufen Sie prepare mit dem App-Namen und den Dateimetadaten auf, laden Sie die Bytes auf das zurückgegebene signierte Ziel hoch und rufen Sie dann deploy auf.
Lokales Quellverzeichnis	Der Codierungsagent archiviert den beabsichtigten Arbeitsbereich-Quellcode lokal in eine ZIP-Datei und folgt dann dem ZIP-Ablauf. Ein lokaler Pfad oder Gesprächskontext ist kein API-unterstützter Quell-Upload.

Beim Packen eines Verzeichnisses fügen Sie den Quellcode, Manifeste, Sperrdateien, Konfiguration und beabsichtigte nicht committete Änderungen ein, die zum Erstellen erforderlich sind. Schließen Sie Anmeldeinformationen, .git, installierte Abhängigkeiten und generierte Artefakte aus. Das Packen und der signierte Upload erfolgen dort, wo die Dateien zugänglich sind; ein gehosteter MCP-Server kann das lokale Verzeichnis des Codierungsagenten nicht lesen.

Für eine vorhandene ZIP-Datei bereiten Sie 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 die tatsächliche ZIP-Datei beschreiben; size_bytes, content_type und md5 sind optional und nullable. Zusätzliche Vorbereitungsfelder werden für die Backend-Validierung beibehalten, wie von OpenAPI erlaubt. Die Vorbereitung gibt projectId, sourceId und upload zurück, einschließlich der uploadUrl, method, headers und expiresAt jeder Datei. Laden Sie die Dateibytes direkt mit dieser signierten URL, Methode und Headern hoch; bewahren Sie die URL genau auf und fügen Sie dem Speicheranfrage keine Harness-Anmeldeinformationen hinzu. Die Vorbereitungsaktion liest oder lädt keine lokalen Dateien hoch.

Nach einem erfolgreichen Upload stellen Sie explizit bereit:

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

Für JSON-Importe verwenden Sie stattdessen die zurückgegebene id. Die Bereitstellung akzeptiert auch body: {"project_id": "<Vibe app id>"} oder params.app_id; das API-Wire-Feld ist snake_case project_id, obwohl die Vorbereitung camelCase projectId zurückgibt. Das allgemeine project_id des Tools auf oberster Ebene ist ein Harness-Bereichsbezeichner und wird niemals als Vibe-App-ID verwendet. Import und Vorbereitung erstellen die App/Quelle; keiner startet die Bereitstellung. Schreibvorgänge werden nicht automatisch wiederholt, und die Bereitstellung verwendet die bestehende Richtlinie für Bestätigungen mit hohem Risiko.

Lesen Sie den Fortschritt mit harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>"). Es behält App-URLs, Ausführungsphasen, Unterschritte, Fehler, Protokollzeilen und Build-Analyzer-Details bei. Die events-Ausführungsaktion akzeptiert resource_id oder params.app_id und verbraucht den SSE-Endpunkt als endlichen Batch: bis zu 20 JSON-Ereignisse oder fünf Sekunden nach der Verbindung, mit einem Antwortlimit von 1 MiB. Diese Grenzwerte gehören zum Vibe-Endpunkt. Die HARNESS_API_TIMEOUT_MS der Verbindung begrenzt auch Verbindungs- und Stream-Verbrauch zusammen; Ablauf gibt einen Timeout-Fehler zurück. Ein abgeschlossener Batch gibt events und stop_reason zurück (end, event_limit oder duration_limit) und schließt den Stream. Weder anfängliche Verbindungsfehler noch unterbrochene Streams werden wiederholt. Ereignisse sind transiente Diffs ohne dokumentierten Wiedergabe-Cursor; verwenden Sie Lifecycle-Abruf für eine autoritative Momentaufnahme. Beide Lifecycle-Lesevorgänge sind im Nur-Lese-Modus verfügbar.

Feature-Flags

Ressourcentyp	Liste	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 (Split.io)-Ressourcen — fme_*-Ressourcen unterstützen Dual-Mode-Bereichsdefinition: Legacy-Aufrufe übergeben workspace_id und treffen die Split.io-API (api.split.io); neuere Aufrufe übergeben org_id+project_id zusammen und treffen Harness-native Endpunkte (standard HARNESS_API_KEY/HARNESS_BASE_URL, gleiche Authentifizierung wie jede andere harness_*-Ressource) stattdessen. Das Übergeben von sowohl workspace_id als auch org_id/project_id im selben Aufruf oder das Mischen von org_id mit project_id allein ist ein Fehler — wählen Sie einen Modus pro Aufruf. Jede Operation unten ist im Legacy-Modus unverändert verfügbar, es sei denn, die Ressource ist als nur Harness-nativ markiert. Die Abdeckung des Harness-nativen Modus ist derzeit schmaler:

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

• fme_environment — Dual-Modus list (workspace_id oder org_id+project_id). get/create/update/delete sind nur Harness-nativ (/fme/api/v4/environments) — MCP hatte nie einen workspace_id-Vertrag für diese Operationen. Native Liste verwendet optionale offset/limit (max. 100; harness_list size wird auf limit abgebildet); Envelope {data, limit, offset, totalCount} wird zu items/total hochgestuft. Native Erstellung/Aktualisierung verwendet isProduction (production wird als Alias akzeptiert). Native Aktualisierung ist JSON Merge Patch; name und isProduction sind nicht löschbar. Name maximal 15 Zeichen.

• fme_feature_flag — Dual-Modus, beide Zweige vollständig verdrahtet. Harness-nativ (org_id+project_id): list/get/create/delete treffen auf /fme/api/v4/feature-flags (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 treffen auf /fme/api/v4/feature-flags/{name}/archive|unarchive (nur optional comment — kein title, gemäß ArchiveUnarchiveRequest); kill/restore/reallocate treffen auf /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate mit environment_id als Query-Parameter (optional comment/title, gemäß FeatureFlagDefinitionActionRequest).

• fme_feature_flag_definition — get/create/update bleiben Dual-Modus (workspace_id oder org_id+project_id). list/delete/kill/restore/reallocate sind nur Harness-nativ (org_id+project_id) — MCP hatte nie einen workspace_id-Vertrag für diese Operationen. Native Liste erfordert feature_flag_name und verwendet offset/limit (Standard 100, max. 100); sie akzeptiert kein environment_id. Löschen und Ausführen erfordern environment_id. Kill/Restore/Reallocate sind dieselben Aktionen wie bei fme_feature_flag. Get/Create/Update-Body entspricht Legacy (treatments, defaultTreatment, defaultRule, optional rules/baselineTreatment/trafficAllocation/comment), plus optional title im Harness-nativen Modus. Native Aktualisierung ist JSON Merge Patch.

• fme_rollout_status — Dual-Modus list. Übergeben Sie org_id+project_id (bevorzugt) oder das veraltete workspace_id. Native Paginierung verwendet offset/limit (max. 100; harness_list size wird auf limit abgebildet); Ergebnisse werden zu items/total hochgestuft. Jedes Element hat id, name und optional description.

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

• fme_rule_based_segment_definition — (Veraltet — siehe fme_segment_definition.) Der Harness-native Modus wird bei jeder Operation/Aktion abgelehnt (list/update/enable/disable/change_request) — verwenden Sie stattdessen fme_segment_definition (kein enable/disable/change_request-Äquivalent dort); diese Ressource unterstützt nur den Legacy-workspace_id/environment_id-Vertrag.

• fme_traffic_type — Dual-Modus list. Übergeben Sie org_id+project_id (bevorzugt) oder das veraltete workspace_id. Native Paginierung verwendet offset/limit (max. 100; harness_list size wird auf limit abgebildet); Ergebnisse werden zu items/total hochgestuft. Jedes Element hat id und name (kein displayAttributeId).

• fme_identity — create/update sind noch nicht implementiert, wenn org_id+project_id zusammen übergeben werden; andernfalls wird wie bei einem normalen Legacy-Aufruf fortgefahren.

• fme_standard_segment — veraltet. Legacy-workspace_id trifft weiterhin auf Split v2. Harness-nativ wird abgelehnt — verwenden Sie fme_segment.

• fme_segment_keys — list/update bleiben Legacy (workspace_id / environment_id+segment_name). Harness-nativ (org_id+project_id) wird abgelehnt — verwenden Sie 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 plus execute list_keys/add_keys/remove_keys. Update ist nur Beschreibung. Löschen schlägt mit hasDependents fehl, solange Schlüssel vorhanden sind.

• fme_metric — Nur Harness-nativ (keine Legacy-workspace_id-Unterstützung). list/get/create/update/delete sind mit /fme/api/v4/metrics verdrahtet (list's harness_list size wird auf limit abgebildet). create erfordert spread, obwohl das Backend CreateMetricRequest es optional hält (Standard PER) — ein strengerer Vertrag nur auf MCP-Seite, da das Weglassen die Semantik einer RATE-Metrik stillschweigend ändert. update ist JSON Merge Patch; name/trafficType sind unveränderlich und werden nicht akzeptiert. delete ist ein permanentes hartes Löschen (kein Archiv/Wiederherstellen) — klassifiziert als destructive.

• fme_event_type — Nur Harness-nativ (keine Legacy-workspace_id-Unterstützung). Schreibgeschützt: list/get sind mit /fme/api/v4/event-types verdrahtet; id ist der Ereignisname. Nur Ereignistypen mit Ereignissen in den letzten 30 Tagen sind sichtbar; get gibt einen 404 zurück für einen Ereignistyp außerhalb des Traffic-Type-Bereichs des anfragenden Workspace oder wenn er länger als 30 Tage inaktiv war. Listenfilter: name (Teilzeichenfolge), traffic_type (nach ID oder Name), offset/limit (harness_list size wird auf limit abgebildet). Verwenden Sie dies, um echte Ereignistyp-IDs zu ermitteln, bevor Sie eine in fme_metric's baseEventTypes/filterEventType oder event_type_ids-Filter referenzieren, anstatt eine ID zu raten.

Im Einzelbenutzer-/Self-Hosted-Modus verwendet die Legacy-Authentifizierung ein Bearer-Token von HARNESS_FME_API_KEY und fällt auf einen Nicht-Platzhalter HARNESS_API_KEY zurück. HARNESS_FME_API_KEY kann ein Legacy-Split-Admin-Schlüssel oder ein FME-berechtigter Harness-PAT/SAT sein, wird jedoch im multi-user-Modus abgelehnt, sodass gemeinsame Bereitstellungen die Anmeldeinformationen des jeweiligen Sitzungsbenutzers nicht überschreiben können. Gehostete OAuth-/Service-Routing-Anmeldeinformationen für Harness-Plattform-APIs authentifizieren keine direkten Split.io-Anfragen. fme_feature_flag unterstützt den vollständigen Lebenszyklus im Legacy-Modus: Erstellen (erfordert traffic_type_id), Auflisten, Abrufen, Aktualisieren von Metadaten, Löschen sowie Kill/Restore/Reallocate/Archive/Unarchive-Ausführungsaktionen. Verwenden Sie fme_traffic_type, um Traffic-Typ-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 Aktivieren/Deaktivieren und Änderungsanfrage-Genehmigungsabläufen verwaltet.

GitOps

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Ausführungsaktionen
gitops_agent	x	x
gitops_argo_project	x
gitops_app_project_mapping	x		x	x	x	import
gitops_autocreate_log	x
gitops_application	x	x				sync
gitops_cluster	x	x
gitops_repository	x	x
gitops_applicationset	x	x
gitops_repo_credential	x	x
gitops_app_event	x
gitops_pod_log		x
gitops_managed_resource	x
gitops_resource_action	x
gitops_dashboard		x
gitops_app_resource_tree		x
gitops_cluster_link	x		x		x

Chaos Engineering

Ressourcentyp	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
chaos_experiment	x	x	x		x	run, stop
chaos_experiment_run		x
chaos_experiment_variable	x
chaos_component_variable		x
chaos_input_set	x	x	x	x	x
chaos_experiment_template	x	x			x	create_from_template, list_revisions, get_variables, get_yaml, compare_revisions
chaos_probe	x	x	x		x	enable, verify, get_manifest
chaos_probe_in_run	x
chaos_probe_template	x	x			x	get_variables
chaos_infrastructure	x
chaos_k8s_infrastructure	x	x	x			check_health
chaos_enabled_infrastructure	x
chaos_environment	x
chaos_hub	x	x	x	x	x
chaos_hub_fault	x
chaos_fault	x	x			x	get_variables, get_yaml
chaos_fault_template	x	x			x	list_revisions, get_variables, get_yaml, compare_revisions
chaos_fault_experiment_run	x
chaos_action	x	x	x		x	get_manifest
chaos_action_template	x	x			x	list_revisions, get_variables, compare_revisions
chaos_loadtest	x	x	x	x	x	run, stop
chaos_service	x	x	x	x	x	list_experiment_runs, list_load_tests
chaos_application_map	x	x
discovered_agent	x
discovered_namespace	x
discovered_service	x
discovered_network_map	x
chaos_guard_condition	x	x			x
chaos_guard_rule	x	x			x	enable
chaos_recommendation	x	x
chaos_risk	x	x
chaos_dr_test	x		x
scanned_risk	x	x				occurrences, summary_by_service
chaos_risk_rule	x	x
chaos_risk_scan	x	x	x	x	x	retry, abort, report, report_download, heatmap

Cloud-Kostenmanagement (CCM)

Ressourcentyp	Liste	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-Einblicke (SEI)

SEI-Ressourcen sind aus Gründen der Token-Effizienz konsolidiert. Verwenden Sie die Parameter metric oder aspect für DORA, Team-/Organisationsstruktur-Details und KI-Einblicke.

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

Software-Lieferketten-Sicherstellung (SCS)

Ressourcentyp	Liste	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-Attestierungen (SDLC-Nachweise). Liste unterstützt Konto-/Organisations-/Projektbereich über resource_scope. Einzelne Freitextfilter (Pipeline, Artefakt allein, Gitoid) verwenden search_term; eine zusätzliche Namenseinschränkung verwendet filters.subject_name; der Inhalts-Digest des Subjekts verwendet filters.subject_digest. Abrufen sucht über gitoid_sha256 und erfordert org_id/project_id (aus der Listenzeile). Herunterladen (harness_execute-Aktion download) gibt einen zeitlich begrenzten download_url zurück – zeigen Sie diesen Link dem Benutzer immer. Erfordert Feature-Flag SCS_EVIDENCE_VAULT.

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

Security Testing Orchestration (STO)

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

security_exemption Erstellen ist eine high_write-Operation. Der Server leitet requester_id aus dem authentifizierten PAT ab, setzt exemptFutureOccurrences=true und setzt duration_days standardmäßig auf 30, wenn nicht angegeben. Zum Auflisten von Ausnahmen übergeben Sie eine kleine explizite Seitengröße (z. B. filters: { "status": "Pending", "size": 5 }) und folgen Sie dem _nextPageHint, das in jeder Antwort zurückgegeben wird.

Workflow zum Ausführen von Sicherheitsausnahmen:

• Verwenden Sie harness_list mit resource_type="security_exemption" und einem expliziten status wie 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 im bestehenden Bereich der Ausnahme; die anderen Bereiche verwenden intern den STO-Promote-Endpunkt. Der Server füllt body.approver_id automatisch aus dem authentifizierten Benutzer aus, wenn es weggelassen wird; body.comment ist optional.
• Verwenden Sie action="reject", um eine Ausnahme abzulehnen. body.approver_id wird ebenfalls automatisch ausgefüllt, wenn es weggelassen wird.
• Es gibt keine separate promote-Aktion zum Ausführen. Verwenden Sie action="approve" mit einem nicht-CURRENT body.scope, wenn das angeforderte Ergebnis eine Genehmigung auf Konto-, Organisations- oder Projektbereich ist.

Zugriffskontrolle

Ressourcentyp	Liste	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	Liste	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	Liste	Abrufen	Erstellen	Aktualisieren	Löschen	Aktionen ausführen
freeze_window	x	x	x	x	x	toggle_status
global_freeze		x				manage

Service-Overrides

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

Einstellungen

Ressourcentyp	Liste	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-Repo scannen, CI-Pipeline generieren (Docker-Image bauen und pushen), K8s-Manifeste ermitteln oder generieren, CD-Pipeline erstellen und bereitstellen – mit automatischem Wiederholungsversuch bei CI-Fehlern (bis zu 5 Versuche) und CD-Fehlern (bis zu 3 Versuche mit Benutzerfreigabe). Nach erschöpften Wiederholungsversuchen werden Deep-Links zur Harness-Benutzeroberfläche für alle erstellten Ressourcen zur manuellen 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 Stage-/Step-Aufschlüsselung, Fehlerdetails, Delegate-Informationen und Logs des fehlgeschlagenen Steps über harness_diagnose ab und liefert dann Ursachenanalyse und Lösungsvorschläge. Folgt automatisch verketteten Pipeline-Fehlern.	executionId (optional), projectId (optional)
pipeline_summarizer	Alle Step-Logs einer Pipeline-Ausführung abrufen und zusammenfassen. Verwendet harness_diagnose mit include_logs: true, include_all_step_logs: true, um die Logs jedes Steps zu erhalten, und präsentiert dann eine Tabelle mit Step-Name, Status, Dauer und Was ist passiert (Log-basierte Zusammenfassung). Überspringt KEINE Steps.	executionId (optional), projectId (optional)
create-pipeline	Eine neue Pipeline-YAML aus natürlichen Sprach-Anforderungen generieren, unter Berücksichtigung vorhandener Ressourcen für den Kontext	description (erforderlich), projectId (optional)
create-agent	Interaktiv einen Harness-AI-Agenten aufbauen – vorhandene Agenten prüfen (aktuelles agent.uses- vs. Legacy-agent.step.group.steps-Spec-Format bei Updates erkennen), Anforderungen sammeln, die Agenten-Spec im passenden Format generieren, mit dem Benutzer bestätigen und dann über harness_create/harness_update erstellen oder aktualisieren	agent_name (erforderlich), task_description (erforderlich), org_id (optional), project_id (optional)
onboard-service	Durch das Onboarding eines neuen Dienstes mit Umgebungen und einer Bereitstellungs-Pipeline führen	serviceName (erforderlich), projectId (optional)
dora-metrics-review	DORA-Metriken überprüfen (Bereitstellungshäufigkeit, Änderungsfehlerrate, MTTR, Durchlaufzeit) mit Elite/Hoch/Mittel/Niedrig-Klassifizierung und Verbesserungsempfehlungen	teamRefId (optional), dateStart (optional), dateEnd (optional)
setup-gitops-application	Durch das Onboarding einer GitOps-Anwendung führen – Agent, Cluster, Repo verifizieren und die Anwendung erstellen	agentId (erforderlich), projectId (optional)
chaos-resilience-test	Ein Chaos-Experiment entwerfen, um die Dienstresilienz mit Fehlerinjektion, Prüfpunkten und erwarteten Ergebnissen zu testen	serviceName (erforderlich), projectId (optional)
feature-flag-rollout	Ein progressives Feature-Flag-Rollout über Umgebungen mit Sicherheitskontrollpunkten planen und ausführen	flagIdentifier (erforderlich), projectId (optional)
migrate-pipeline-to-template	Eine vorhandene Pipeline analysieren und wiederverwendbare Stage-/Step-Vorlagen daraus extrahieren	pipelineId (erforderlich), projectId (optional)
delegate-health-check	Delegate-Konnektivität, -Gesundheit, -Token-Status prüfen und Infrastrukturprobleme beheben	projectId (optional)
developer-portal-scorecard	IDP-Scorecards für Dienste überprüfen und Lücken zur Verbesserung der Entwicklererfahrung identifizieren	projectId (optional)
pending-approvals	Pipeline-Ausführungen finden, die auf Genehmigung warten, Details anzeigen und Genehmigen oder Ablehnen anbieten	projectId (optional), orgId (optional), pipelineId (optional)

FinOps

Prompt	Beschreibung	Parameter
optimize-costs	Cloud-Kostendaten analysieren, Empfehlungen und Anomalien aufdecken, priorisiert nach potenziellen Einsparungen	projectId (optional)
cloud-cost-breakdown	Detaillierte Analyse der Cloud-Kosten nach Dienst, Umgebung oder Cluster mit Trendanalyse und Anomalieerkennung	perspectiveId (optional), projectId (optional)
commitment-utilization-review	Reserved-Instance- und Savings-Plan-Nutzung analysieren, um Verschwendung zu finden und Verpflichtungen zu optimieren	projectId (optional)
cost-anomaly-investigation	Kostenanomalien untersuchen – Ursache, betroffene Ressourcen und Abhilfemaßnahmen ermitteln	projectId (optional)
rightsizing-recommendations	Rightsizing-Empfehlungen überprüfen und priorisieren, optional Jira- oder ServiceNow-Tickets erstellen	projectId (optional), minSavings (optional)

DevSecOps

Prompt	Beschreibung	Parameter
security-review	Sicherheitsprobleme in Harness-Ressourcen überprüfen und Abhilfemaßnahmen nach Schweregrad vorschlagen	projectId (optional), severity (optional, Standard: critical,high)
vulnerability-triage	Sicherheitslücken in Pipelines und Artefakten priorisieren, nach Schweregrad und Ausnutzbarkeit sortieren	projectId (optional), severity (optional)
sbom-compliance-check	SBOM- und Compliance-Status für Artefakte prüfen – Lizenzrisiken, Richtlinienverstöße, Komponenten-Schwachstellen	artifactId (optional), projectId (optional)
supply-chain-audit	End-to-End-Sicherheitsaudit der Software-Lieferkette – Herkunft, Nachweiskette, Richtlinienkonformität	projectId (optional)
security-exemption-review	Ausstehende Sicherheitsfreigaben überprüfen und Batch-Entscheidungen zur Genehmigung oder Ablehnung treffen	projectId (optional)
bulk-exemption-create	Begründete Sicherheitsfreigaben für mehrere STO-Probleme mit explizitem Umfang und Dauer erstellen	projectId (erforderlich), exemption_type (erforderlich), reason (erforderlich), Problemfilter (optional)
access-control-audit	Benutzerberechtigungen, überprivilegierte Konten und Rollenzuweisungen prüfen, um das Prinzip der geringsten Rechte durchzusetzen	projectId (optional), orgId (optional)

Harness Code

Prompt	Beschreibung	Parameter
code-review	Pull Request überprüfen — Diff, Commits, Checks und Kommentare analysieren, um strukturiertes Feedback zu Bugs, Sicherheit, Leistung und Stil zu geben	repoId (erforderlich), prNumber (erforderlich), projectId (optional)
pr-summary	Automatisch einen PR-Titel und eine Beschreibung aus dem Commit-Verlauf und 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}	Pipeline-YAML-Definition	application/x-yaml
pipeline:///{orgId}/{projectId}/{pipelineId}	Pipeline-YAML (mit explizitem Geltungsbereich)	application/x-yaml
executions:///recent	Letzte 10 Pipeline-Ausführungszusammenfassungen	application/json
schema:///pipeline	Harness-Pipeline-JSON-Schema	application/schema+json
schema:///template	Harness-Vorlagen-JSON-Schema	application/schema+json
schema:///trigger	Harness-Trigger-JSON-Schema	application/schema+json
schema:///pipeline_v1 (Alpha)	Harness-V1-Pipeline-JSON-Schema (vereinfachtes Stages/Steps-Format)	application/schema+json
schema:///agent-pipeline	Harness-AI-Agent-Pipeline-JSON-Schema	application/schema+json
agent-docs:///legacy-format	Legacy-Agent-Spezifikationsformat-Referenz (agent.step.group.steps / PLUGIN_TASK), gelesen vom create-agent-Prompt beim Aktualisieren eines vorhandenen Legacy-Format-Agents	text/markdown

Toolset-Filterung

Standardmäßig sind 41 von 45 Toolsets aktiviert. Vier Toolsets sind optional und von den Standardeinstellungen ausgeschlossen:

• ansible — Harness Ansible (Inventare, Playbooks, Hosts, Aktivität). Optional, da es projektspezifisch ist und Konzepte hinzufügt, die viele Benutzer nicht benötigen.
• autonomous_work — Development Harness (autonome Arbeit). Optional; siehe Toolset-Beschreibung für den Geltungsbereich.
• observability-evaluations — Geplante Produktionstelemetrie-Bewertungsregeln. Optional, da es von der bereitgestellten Scoring-Steuerungsebene abhängt.
• 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.

Hinzufügen von Toolsets mit +-Präfix

Verwenden Sie das +-Präfix, um optionale Toolsets explizit zusammen mit allen Standardeinstellungen einzuschließen:

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

Entfernen von Standard-Toolsets

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

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

Kombinieren von + und -

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

Explizite Zulassungsliste

Eine explizite, durch Kommas getrennte Liste (ohne Präfixe) ersetzt die Standardeinstellungen 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
infrastructure	infrastructure
secrets	secret
logs	execution_log
audit	audit_event
delegates	delegate, delegate_token
repositories	repository, branch, commit, file_content, tag, repo_rule, space_rule
registries	registry, artifact, artifact_version, artifact_file
file_store	file_store
templates	template
dashboards	dashboard, dashboard_data
idp	idp_entity, scorecard, scorecard_check, scorecard_stats, scorecard_check_stats, idp_score, idp_workflow, idp_tech_doc
pull-requests	pull_request, pr_reviewer, pr_comment, pr_check, pr_activity
feature-flags	fme_workspace, fme_environment, fme_feature_flag, fme_feature_flag_definition, fme_rollout_status, fme_rule_based_segment, fme_rule_based_segment_definition, fme_traffic_type, fme_identity, fme_standard_segment, fme_segment_keys, fme_segment, fme_segment_definition, fme_metric, fme_event_type
gitops	gitops_agent, gitops_argo_project, gitops_app_project_mapping, gitops_autocreate_log, gitops_application, gitops_cluster, gitops_repository, gitops_applicationset, gitops_repo_credential, gitops_app_event, gitops_pod_log, gitops_managed_resource, gitops_resource_action, gitops_dashboard, gitops_app_resource_tree, gitops_cluster_link
chaos	chaos_experiment, chaos_experiment_run, chaos_experiment_variable, chaos_component_variable, chaos_input_set, chaos_experiment_template, chaos_probe, chaos_probe_in_run, chaos_probe_template, chaos_infrastructure, chaos_k8s_infrastructure, chaos_enabled_infrastructure, chaos_environment, chaos_hub, chaos_hub_fault, chaos_fault, chaos_fault_template, chaos_fault_experiment_run, chaos_action, chaos_action_template, chaos_loadtest, chaos_service, chaos_application_map, discovered_agent, discovered_namespace, discovered_service, discovered_network_map, chaos_guard_condition, chaos_guard_rule, chaos_recommendation, chaos_risk, chaos_dr_test, scanned_risk, chaos_risk_rule, chaos_risk_scan
ccm	cost_perspective, cost_breakdown, cost_timeseries, cost_summary, cost_recommendation, cost_anomaly, cost_anomaly_summary, cost_category, cost_account_overview, cost_filter_value, cost_recommendation_stats, cost_recommendation_detail, cost_commitment
sei	sei_metric, sei_productivity_metric, sei_dora_metric, sei_team, sei_team_detail, sei_org_tree, sei_org_tree_detail, sei_business_alignment, sei_ai_usage, sei_ai_adoption, sei_ai_impact, sei_ai_raw_metric
scs	scs_artifact_source, artifact_security, scs_artifact_component, scs_artifact_remediation, scs_chain_of_custody, scs_compliance_result, code_repo_security, scs_sbom
evidence-vault	attestation
sto	security_issue, security_issue_filter, security_exemption, remediation_diff
dbops	database_schema, database_instance, database_snapshot_object, database_llm_authoring_pipeline
autonomous_work (opt-in)	work_item, work_item_resume, work_item_approve, work_timeline, work_budget, work_phase, work_phase_artifact, work_artifact, budget, budget_grant, budget_usage, work_class, work_trigger, capability, risk_evaluator, team, member, member_template, software_component, content_source_connector
access_control	user, user_group, service_account, role, role_assignment, resource_group, permission
governance	policy, policy_set, policy_evaluation
freeze	freeze_window, global_freeze
overrides	service_override
settings	setting
knowledge-graph	kg_queryable_type_summary, kg_grammar, hql_query
semantic-layer	kg_type, kg_related_type
ai-evals	eval_dataset, eval_dataset_item, evaluation, eval_run, eval_run_item, eval_run_by_eval, eval_metric, eval_metric_set, eval_metric_set_entry, eval_suite, eval_suite_evaluation, eval_suite_run, eval_target, eval_annotation, eval_analytics, eval_git_settings, eval_registry_item, eval_git_registration, online_eval
observability-evaluations (opt-in)	observability_evaluation_rule
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

Architektur

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

So funktioniert es

1. Tools sind generische Verben: harness_list, harness_get, usw. Sie akzeptieren einen resource_type-Parameter, der zum korrekten API-Endpunkt weiterleitet.
2. Die Registry ordnet jedem resource_type eine ResourceDefinition zu — eine deklarative Datenstruktur, die HTTP-Methode, URL-Pfad, Pfad-/Query-Parameter-Zuordnungen und die Logik zur Antwort-Extraktion festlegt.
3. Dispatch löst die Ressourcendefinition auf, erstellt die HTTP-Anfrage (Pfad-Substitution, Query-Parameter, resource_scope-bewusste Konto-/Organisations-/Projekt-Injektion), ruft die Harness-API über HarnessClient auf und extrahiert die relevanten Antwortdaten.
4. 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 in objektförmige structuredContent für strikte Clients um.
6. Deep Links werden automatisch an Antworten angehängt und liefern direkte Harness-UI-URLs für jede Ressource.
7. Kompaktmodus entfernt ausführliche Metadaten aus Listenergebnissen und behält nur umsetzbare Felder (Identität, Status, Typ, Zeitstempel, Deep Links), um die Token-Nutzung zu minimieren.

Hinzufügen eines neuen Ressourcentyps

Erstellen Sie eine neue Datei in src/registry/toolsets/ oder fügen Sie eine Ressource zu einem bestehenden 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",
        },
      },
    },
  ],
};

Importieren Sie sie dann in src/registry/index.ts und fügen Sie sie dem ALL_TOOLSETS-Array hinzu. Keine Änderungen an Tool-Dateien 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

Elicitation

Die Schreib-Tools (harness_create, harness_update, harness_delete, harness_execute) verwenden MCP-Elicitation, um den Benutzer zur Bestätigung aufzufordern, wenn das Risiko der Aktion dies erfordert — nur bei medium_write, high_write und destructive-Operationen. Risikoarme Erstellungen / Aktualisierungen / Lesevorgänge (z. B. pipeline.create, pipeline.update, hql_query.run) werden ohne Eingabeaufforderung stillschweigend ausgeführt. Wenn eine Eingabeaufforderung angezeigt wird, sieht der Benutzer, was gleich passieren wird, und akzeptiert oder lehnt ab — echte Mensch-in-der-Schleife-Genehmigung für die Operationen, die tatsächlich etwas verändern oder ausführen.

So funktioniert es:

1. Das LLM ruft ein Schreib-Tool mit medium_write+ Risiko auf (z. B. harness_delete, harness_execute pipeline.run). Risikoarme Erstellungen / Aktualisierungen / Lesevorgänge zeigen keine Eingabeaufforderung an.
2. Der Server sendet eine Elicitation-Anfrage an den Client mit einer Zusammenfassung der Operation und einem confirm-Kontrollkästchen (standardmäßig aktiviert).
3. Der Benutzer sieht die Details und klickt auf Akzeptieren (mit aktiviertem confirm) oder Ablehnen / Abbrechen.
4. Wenn mit aktiviertem confirm: true akzeptiert, wird die Operation fortgesetzt. Wenn mit deaktiviertem confirm akzeptiert, abgelehnt oder abgebrochen, wird sie blockiert und das LLM wird informiert (eine explizite Ablehnung ist maßgeblich und wird nicht durch confirm: true beim Tool-Aufruf umgangen).

Client-Unterstützung:

Client	Elicitation-Unterstützung
Cursor	Ja
VS Code (Copilot)	Ja
Claude Desktop	Noch nicht
Devin Desktop	Noch nicht
MCP Inspector	Ja

Das Elicitation-Verhalten variiert je nach Operationsrisiko, wenn die Client-Unterstützung fehlt:

Risikostufe	Client unterstützt Elicitation	confirm: true übergeben	Verhalten
read, low_write	beliebig	beliebig	Still fortfahren — keine Eingabeaufforderung wird angezeigt (confirm hat auf dieser Risikostufe keine Wirkung)
medium_write, high_write, destructive	Ja	beliebig	Benutzer auffordern. Nur fortfahren, wenn der Benutzer mit confirm: true akzeptiert (der Schema-Standard). Eine explizite Ablehnung, ein Abbrechen oder ein Akzeptieren mit confirm: false (Benutzer hat das Kontrollkästchen deaktiviert) ist maßgeblich und wird nicht durch confirm: true beim Tool-Aufruf umgangen. Ein Akzeptieren ohne das confirm-Feld wird so behandelt, als ob der Client keine brauchbare Eingabeaufforderung anzeigen konnte — behebbar durch erneuten Versuch mit confirm: true
medium_write, high_write, destructive	Nein	Nein	BLOCKIEREN (Fehler mit Hinweis auf erneuten Versuch mit confirm: true zurückgeben)
medium_write, high_write, destructive	Nein	Ja	Fortfahren (explizites Opt-in für nicht-interaktive Automatisierung)
beliebig (bei oder unter HARNESS_AUTO_APPROVE_RISK)	beliebig	beliebig	Automatisch genehmigen ohne Eingabeaufforderung

Wenn elicitInput zur Laufzeit fehlschlägt (Transportfehler, nicht unterstützte Methode) für eine medium_write+ Operation, wird der Aufruf blockiert, es sei denn, der Aufrufer übergibt confirm: true. confirm: true wird als Fallback berücksichtigt, wenn der Client keine Eingabeaufforderung anzeigen konnte oder ein degeneriertes Akzeptieren zurückgab ({action: "accept"} ohne das Bestätigungsfeld), überschreibt jedoch nicht eine explizite Ablehnung/ein Abbrechen von einem Client, der den Elicitation-Handshake abgeschlossen hat.

Autonomer Modus

Autonomer Modus bedeutet, dass der Server alle Operationen — einschließlich Schreib- und destruktiver Aktionen — ohne Bestätigungsaufforderung ausführt. Aktivieren Sie ihn durch Setzen von:

HARNESS_AUTO_APPROVE_RISK=all

Dies ist die Obergrenze auf Bereitstellungsebene: Einmal gesetzt, können einzelne Sitzungen nicht darüber hinaus eskalieren (obwohl sie pro Sitzung einen strengeren Schwellenwert über den x-harness-auto-approve-risk-Header wählen können).

Oder in Ihrer MCP-Client-Konfiguration:

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

Teilautonomie: Sie können auch nur bis zu einer bestimmten Risikostufe automatisch genehmigen und bei risikoreicheren Operationen 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 Auto-Genehmigungs-Schwellenwert
low_write	Lesevorgänge + risikoarme Schreibvorgänge
medium_write	Lesevorgänge + risikoarme + mittlere Schreibvorgänge
high_write	Lesevorgänge + risikoarme + mittlere + risikoreiche Schreibvorgänge
all	Alles, einschließlich destruktiver Operationen

Warnung zum autonomen Modus: HARNESS_AUTO_APPROVE_RISK=all überspringt die Bestätigung für alle Operationen, einschließlich harness_delete. Mit Vorsicht verwenden und erwägen, mit HARNESS_TOOLSETS zu kombinieren, um einzuschränken, welche Ressourcentypen verfügbar sind.

Migrationshinweis: HARNESS_SKIP_ELICITATION=true wird weiterhin unterstützt und wird auf HARNESS_AUTO_APPROVE_RISK=all abgebildet. Eine Abkündigungswarnung wird an stderr protokolliert. Wenn beide gesetzt sind, hat HARNESS_AUTO_APPROVE_RISK Vorrang.

Sicherheit

• Geheimnisse werden niemals offengelegt. Der secret-Ressourcentyp gibt nur Metadaten zurück (Name, Typ, Bereich) — Geheimniswerte sind niemals in einer Antwort enthalten.
• Bestätigungspflichtige Operationen verwenden Elicitation, wenn verfügbar. Wenn eine Schreib- oder Ausführungsaktion medium_write, high_write oder destructive-Risiko hat, versuchen harness_create, harness_update, harness_delete und harness_execute vor dem Fortfahren eine MCP-Elicitation (siehe Elicitation). Risikoarme Aktionen (read, low_write — z. B. pipeline.create, pipeline.update, hql_query.run) werden ohne Eingabeaufforderung stillschweigend ausgeführt.
• Mittleres Risiko und darüber schließen fehlersicher ab. Wenn für medium_write, high_write oder destructive-Operationen keine Bestätigung eingeholt werden kann, werden sie blockiert, statt blind ausgeführt zu werden. Überschreiben mit HARNESS_AUTO_APPROVE_RISK für autonome Workflows.
• CORS auf gleiche Herkunft beschränkt. Der HTTP-Transport erlaubt nur Anfragen gleicher Herkunft und verhindert so CSRF-Angriffe von bösartigen Websites, die auf den MCP-Server auf localhost abzielen.
• HTTP-Ratenbegrenzung. Der HTTP-Transport erzwingt 60 Anfragen pro Minute pro IP, um Anfrageflut zu verhindern.
• API-Ratenbegrenzung. Der Harness-API-Client erzwingt ein Limit von 10 Anfragen pro Sekunde, um upstream-Ratenbegrenzungen zu vermeiden.
• Seitengrenzen durchgesetzt. Listenabfragen sind auf insgesamt 10.000 Elemente und 100 pro Seite begrenzt, um Speichererschöpfung zu verhindern.
• Wiederholungen mit Backoff. Vorübergehende Fehler (HTTP 429, 5xx) werden mit exponentiellem Backoff und Jitter wiederholt.
• Localhost-Bindung. Der HTTP-Transport bindet standardmäßig an 127.0.0.1 — nicht aus dem Netzwerk erreichbar.
• Kein stdout-Logging. Alle Logs gehen an stderr, um eine Beschädigung des stdio-JSON-RPC-Transports zu vermeiden.

Komplementäre Skills

Der Harness-MCP-Server passt gut zu Harness Skills — einer Sammlung vorgefertigter Claude-Code-Skills (Slash-Befehle), die für gängige Harness-Workflows entwickelt wurden. Installieren Sie sie zusammen mit diesem MCP-Server, um High-Level-Automatisierung wie /deploy, /rollback, /triage und mehr ohne eigene Prompt-Erstellung zu erhalten.

Fehlerbehebung & Häufige Fallstricke

Symptom	Wahrscheinliche Ursache	Was zu tun ist
HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...	API-Schlüssel liegt nicht in einem unterstützten, kontobezogenen Format vor (pat.<accountId>... oder sat.<accountId>...), daher kann die Konto-ID nicht abgeleitet werden	Setze HARNESS_ACCOUNT_ID explizit
Unknown transport: "..." beim Start	Nicht unterstütztes CLI-Transport-Argument	Verwende nur stdio oder http
Invalid HARNESS_TOOLSETS: ... beim Start	Ein oder mehrere Toolset-Namen werden nicht erkannt	Verwende nur Namen aus Toolset-Filterung (exakte Übereinstimmung)
HTTP mcp-session-id header is required...	Eine Sitzungsanfrage wurde ohne Sitzungs-Header gesendet	Sende zuerst initialize, dann füge mcp-session-id bei POST/GET/DELETE /mcp hinzu
HTTP Session not found...	Sitzung ist nach MCP_SESSION_TTL_MS Leerlauf-Millisekunden abgelaufen oder bereits geschlossen	Führe initialize erneut aus, um eine neue Sitzung zu erstellen, und wiederhole dann mit neuem Header
HTTP 405 Method Not Allowed bei /mcp	Nicht unterstützte Methode für den MCP-Endpunkt	Verwende nur POST, GET, DELETE oder OPTIONS
HTTP Invalid request	Ungültiger JSON-Body oder Anfrage-Body überschreitet HARNESS_MAX_BODY_SIZE_MB	Überprüfe JSON-Payload-Größe/-Form; erhöhe HARNESS_MAX_BODY_SIZE_MB falls nötig
Unknown resource_type "..." von Tools	Ressourcentyp ist falsch geschrieben oder über HARNESS_TOOLSETS herausgefiltert	Rufe harness_describe auf (mit optionalem search_term), um gültige Typen zu ermitteln
Missing required field "... for path parameter ..."	Ein Projekt-/Organisationsbezogener Aufruf fehlt Identifikatoren	Setze HARNESS_ORG/HARNESS_PROJECT oder übergebe org_id/project_id pro Tool-Aufruf
resource_scope "org" requires org_id... oder resource_scope "project" requires project_id...	Eine Ressource mit mehreren Bereichen wurde ohne ausreichende Identifikatoren auf Organisations-/Projektbereich erzwungen	Übergebe die fehlenden org_id/project_id, konfiguriere HARNESS_ORG/HARNESS_PROJECT oder verwende resource_scope: "account", wenn unterstützt
Read-only mode is enabled ... operations are not allowed	HARNESS_READ_ONLY=true blockiert Erstellen/Aktualisieren/Löschen/Ausführen	Setze HARNESS_READ_ONLY=false, wenn Schreiboperationen beabsichtigt sind
Pipeline-Lauf schlägt vor dem Start fehl mit unaufgelösten erforderlichen Eingaben	Bereitgestellte inputs deckte erforderliche Laufzeit-Platzhalter nicht ab	Rufe runtime_input_template ab, liefere fehlende einfache Schlüssel oder verwende input_set_ids für strukturelle Eingaben
Pipeline-CI-Kurzform (branch, tag, pr_number, commit_sha) wurde nicht angewendet	inputs.build war bereits bereitgestellt, daher wurde die Kurzform-Erweiterung absichtlich übersprungen	Entferne inputs.build, um die Kurzform-Erweiterung zu nutzen, oder behalte die vollständige explizite build-Struktur
Pipeline-Lauf lud die falsche YAML-Revision	Die Pipeline-Definition ist in Git gespeichert und der Lauf spezifizierte nicht den gewünschten Pipeline-Zweig	Übergebe params.pipeline_branch bei der run-Aktion; dies entspricht Harness branch
wait: true gab _wait.error zurück	Der Pipeline-Trigger war erfolgreich, aber die serverseitige Abfrage schlug fehl	Überprüfe erneut den execution_id mit harness_get(resource_type="execution", ...), bevor du entscheidest, ob du erneut ausführst
wait: true gab execution_timed_out: true zurück	Die Ausführung erreichte keinen Endstatus vor wait_timeout_seconds	Verwende den zurückgegebenen execution_id, um den Status erneut zu prüfen; warte auf einen Endstatus, bevor du harness_diagnose ausführst
Ausführungsprotokolle sind leer oder Blob-Downloads geben 403 zurück	Von Harness gehostete Protokoll-Blob-URLs erfordern den konfigurierten Harness-Client/Auth-Pfad, insbesondere für interne oder selbstverwaltete Hosts	Halte HARNESS_BASE_URL auf den Ziel-Harness-Host gerichtet und verwende harness_get(resource_type="execution_log", ...) oder harness_diagnose(..., include_logs=true) anstatt den MCP-Client zu umgehen
Operation declined by user / Operation cancelled by user	Benutzer hat den Bestätigungsdialog zur Elicitation abgelehnt oder abgebrochen — maßgeblich	Überprüfe die Operationsdetails mit dem Benutzer; confirm: true umgeht nicht eine explizite Ablehnung. Der Benutzer muss die Eingabeaufforderung akzeptieren
Operation blocked: the client could not surface a usable confirmation prompt	Client unterstützt keine Elicitation, elicitInput schlug fehl oder gab eine degenerierte Annahme zurück	Wiederhole mit confirm: true für nicht-interaktive Automatisierung oder verwende einen Client, der Elicitation unterstützt
body.template_yaml (or body.yaml) is required für Vorlagen-Erstellen/Aktualisieren	Vorlagen-APIs erwarten vollständige YAML-Payload	Stelle den vollständigen template_yaml-String in body bereit; für Löschungen übergebe version_label, 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	Verwende HTTPS oder setze HARNESS_ALLOW_HTTP=true für lokale Entwicklung

Lizenz

MIT