Harness

Serveur MCP Harness 2.0

Un serveur MCP (Model Context Protocol) qui donne aux agents IA un accès complet à la plateforme Harness.io via 11 outils consolidés et 259 types de ressources.

Pourquoi utiliser ce serveur MCP

La plupart des serveurs MCP mappent un outil par point de terminaison d'API. Pour une plateforme aussi vaste que Harness, cela signifie plus de 240 outils — et les LLM deviennent moins performants dans la sélection d'outils à mesure que le nombre augmente. Les fenêtres de contexte se remplissent de schémas, et chaque nouveau point de terminaison implique du nouveau code.

Ce serveur est conçu différemment :

• 11 outils, 259 types de ressources. Un système de routage basé sur un registre achemine harness_list, harness_get, harness_create, etc. vers n'importe quelle ressource Harness — pipelines, services, environnements, organisations, projets, indicateurs de fonctionnalités, données de coûts, et plus encore. Le LLM choisit parmi 11 outils au lieu de centaines.
• Couverture complète de la plateforme. 42 ensembles d'outils par défaut couvrant CI/CD, GitOps, indicateurs de fonctionnalités, gestion des coûts cloud, tests de sécurité, ingénierie du chaos, DevOps de bases de données, portail interne pour développeurs, chaîne d'approvisionnement logicielle, gestion de l'infrastructure en tant que code, gestion des versions, gouvernance, remplacements de services, graphe de connaissances, et plus encore. Une couverture optionnelle Ansible et d'évaluation de l'observabilité est disponible si nécessaire.
• Workflows multi-projets prêts à l'emploi. Les agents découvrent dynamiquement les organisations et les projets — aucune variable d'environnement codée en dur n'est nécessaire. Demandez « afficher les exécutions échouées sur tous les projets » et l'agent peut naviguer dans toute la hiérarchie du compte.
• 35 modèles de prompts. Des prompts préconstruits pour les workflows courants : créer et déployer des applications de bout en bout, déboguer des pipelines échoués, examiner les métriques DORA, trier les vulnérabilités, optimiser les coûts cloud, auditer le contrôle d'accès, planifier des déploiements d'indicateurs de fonctionnalités, examiner les demandes de tirage, approuver les pipelines en attente, et plus encore.
• Fonctionne partout. Transport Stdio pour les clients locaux (Claude Desktop, Cursor, Devin Desktop), transport HTTP pour les déploiements distants/partagés, prêt pour Docker et Kubernetes.
• Démarrage sans configuration. Fournissez simplement une clé API Harness. L'ID de compte est automatiquement extrait des jetons PAT et SAT, les valeurs par défaut d'organisation/projet sont facultatives, et le filtrage des ensembles d'outils vous permet d'exposer uniquement ce dont vous avez besoin.
• Extensible par conception. Ajouter une nouvelle ressource Harness signifie ajouter un fichier de données déclaratif — aucun nouvel enregistrement d'outil, aucun changement de schéma, aucune mise à jour de prompt.

Prérequis

Avant d'installer ou d'exécuter le serveur, vous avez besoin d'une clé API Harness :

1. Connectez-vous à votre compte Harness
2. Allez dans Mon profil → Clés API → + Nouvelle clé API
3. Créez un nouveau Jeton sous la clé API — cela génère un PAT ou SAT au format <prefix>.<accountId>.<tokenId>.<secret>
4. Enregistrez le jeton dans un endroit sécurisé — vous en aurez besoin à l'étape suivante

Pour des instructions détaillées, consultez le Guide de démarrage rapide de l'API Harness.

Démarrage rapide

Option 0 : MCP Harness hébergé

Si votre compte Harness dispose du service MCP hébergé activé, les clients prenant en charge les serveurs MCP distants peuvent se connecter directement au point de terminaison géré au lieu d'exécuter le serveur localement.

Important : Le service MCP hébergé utilise OAuth de la plateforme Harness, pas HARNESS_API_KEY. Il doit également être activé/configuré par compte par l'assistance Harness avant que le point de terminaison puisse être utilisé.

Voir MCP Harness hébergé pour des exemples de configuration.

Option 1 : npx (recommandé)

Aucune installation requise — exécutez-le simplement :

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

Ou configurez la clé API dans votre client IA (voir Configuration du client ci-dessous).

# 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

Remarque : L'ID de compte est automatiquement extrait des jetons PAT et SAT (pat.<accountId>... ou sat.<accountId>...), donc HARNESS_ACCOUNT_ID n'est nécessaire que pour les clés API sans segment de compte intégré.

Option 2 : Installation globale

npm install -g harness-mcp-v2

# Then run directly
harness-mcp-v2

Option 3 : Compilation à partir des sources

Pour le développement ou la personnalisation :

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

Bundle du répertoire MCP Anthropic

Le manifeste du bundle MCPB se trouve dans [mcp-directory/](mcp-directory/), et l'icône du bundle 512×512 est suivie dans [icon.png](icon.png) à la racine du dépôt. L'archive empaquetée contient manifest.json, icon.png, server/, package.json, npm-shrinkwrap.json au niveau racine, et node_modules/ de production.

Pour garder l'archive légère, construisez les packages MCPB à partir d'un répertoire de préparation :

pnpm prepare:mcpb

Le répertoire de préparation est écrit dans dist/mcpb/ avec les dépendances de production installées depuis npm-shrinkwrap.json en utilisant la disposition plate de npm. Le CLI MCPB officiel épinglé le valide et crée dist/harness-mcp-server-<version>.mcpb.

Les balises de version correspondant à v*.*.* publient automatiquement ce bundle dans la version GitHub correspondante. Pour compléter une version existante sans republier npm, exécutez le workflow Release manuellement avec son entrée release_tag (par exemple, v3.2.20). Le workflow extrait et construit cette balise exacte avant de remplacer uniquement son actif MCPB versionné.

Utilisation en ligne de commande

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

Le transport par défaut est stdio s'il n'est pas spécifié. Utilisez http pour les déploiements distants/partagés.

Transport HTTP

En mode HTTP, le serveur expose :

Point de terminaison	Méthode	Description
/mcp	POST	Point de terminaison MCP JSON-RPC (initialisation + requêtes de session)
/mcp	GET	Flux SSE pour les messages initiés par le serveur (progression, sollicitation)
/mcp	DELETE	Terminer une session MCP active
/mcp	OPTIONS	Pré-vol CORS
/health	GET	Vérification de santé — renvoie { "status": "ok", "sessions": <count> }
/.well-known/oauth-protected-resource	GET	Métadonnées RFC 9728 lorsque HARNESS_MCP_MODE=oauth
/.well-known/oauth-protected-resource/mcp	GET	Métadonnées RFC 9728 sensibles au chemin pour la ressource /mcp par défaut

Le transport HTTP fonctionne en mode basé sur les sessions. Une nouvelle session MCP est créée sur initialize, le serveur renvoie un en-tête mcp-session-id, et les requêtes suivantes pour cette session doivent inclure le même en-tête.

Contraintes opérationnelles en mode HTTP :

• Définissez HARNESS_MCP_AUTH_TOKEN pour les déploiements mono-utilisateur et multi-utilisateurs partagés ou accessibles à distance. Lorsqu'il est défini, chaque requête POST, GET et DELETE vers /mcp doit inclure Authorization: Bearer <token>.
• Le mode OAuth accepte les jetons d'accès HarnessID au lieu de HARNESS_MCP_AUTH_TOKEN et peut se lier à une adresse non-boucle locale sans l'option de désactivation non authentifiée.
• Les liaisons non-boucle locale mono-utilisateur et multi-utilisateurs exigent HARNESS_MCP_AUTH_TOKEN par défaut. Pour exécuter sans authentification sur une interface non-boucle locale quand même, définissez HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP=true explicitement.
• POST /mcp sans mcp-session-id doit être une requête initialize.
• POST /mcp, GET /mcp et DELETE /mcp pour les sessions existantes exigent l'en-tête mcp-session-id.
• GET /mcp est utilisé pour les notifications SSE (mises à jour de progression et invites de sollicitation).
• Les sessions inactives sont supprimées après MCP_SESSION_TTL_MS millisecondes une fois qu'aucune requête ou flux SSE n'est actif (par défaut 1800000, soit 30 minutes).
• GET /health est le seul point de terminaison non-MCP.
• La taille du corps de la requête est plafonnée par HARNESS_MAX_BODY_SIZE_MB (par défaut 10 Mo).
• Définissez x-harness-pipeline-version: 0 ou 1 sur la requête initialize pour sélectionner les ressources de pipeline V0 ou V1 pour cette session HTTP.
• Définissez x-harness-auto-approve-risk: none|low_write|medium_write|high_write|all sur la requête initialize pour choisir un seuil d'approbation automatique par session plus strict. Le serveur plafonne cette valeur au niveau du déploiement HARNESS_AUTO_APPROVE_RISK, donc une session peut réduire mais pas étendre le plafond d'approbation configuré.

Mode OAuth HarnessID

Définissez HARNESS_MCP_MODE=oauth pour permettre aux clients MCP distants de découvrir HarnessID et de compléter le code d'autorisation OAuth 2.1 avec PKCE. Le mode OAuth n'est disponible qu'avec le transport HTTP. Les valeurs par défaut de routage de production HarnessID, ressource MCP et API Harness sont intégrées :

HARNESS_MCP_MODE=oauth

Cela utilise par défaut l'émetteur https://id.harness.io/idp/realms/HarnessIDP, la ressource https://mcp.harness.io/mcp, le client OAuth mcp-client et la base API Harness https://mcp.harness.io/cli. Remplacez-les uniquement pour l'assurance qualité, le développement local ou un autre environnement Harness.

HARNESS_API_KEY ne doit pas être défini dans ce mode. HARNESS_MCP_OAUTH_JWKS_URI utilise par défaut <issuer>/protocol/openid-connect/certs, et HARNESS_ACCOUNT_ID est inutile car le compte provient du jeton.

Le serveur publie les métadonnées de ressource protégée RFC 9728 et renvoie ce défi lorsqu'un client ne s'est pas authentifié :

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

Il valide la signature RS256 du jeton d'accès HarnessID, iss, l'expiration et sub en utilisant le point de terminaison JWKS configuré, et vérifie que le jeton a été émis pour HARNESS_MCP_OAUTH_CLIENT_ID via la revendication azp. HARNESS_MCP_OAUTH_RESOURCE est l'identifiant de ressource protégée RFC 9728 utilisé pour la découverte et les défis. Les jetons d'accès HarnessID actuels utilisent aud: account plutôt que l'URL MCP, donc la ressource n'est pas comparée avec aud.

L'ID de compte provient de la revendication HARNESS_MCP_OAUTH_ACCOUNT_CLAIM du jeton (account_id par défaut), que la portée organization de HarnessID remplit. Chaque session stocke le jeton d'accès de l'appelant et le transmet à l'API Harness comme Authorization: Bearer, donc la RBAC Harness et les enregistrements d'audit reflètent l'utilisateur connecté plutôt qu'un PAT partagé. La session est liée au sub et au compte avec lesquels elle a été créée : une requête ultérieure peut porter un jeton actualisé, mais un jeton pour un utilisateur ou un compte différent est rejeté.

Les clients n'ont normalement besoin que de l'URL de ressource MCP :

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

Le client lit les métadonnées de ressource protégée, découvre HARNESS_MCP_OAUTH_ISSUER, puis utilise les métadonnées RFC 8414 de ce serveur d'autorisation. Si le client ne prend pas en charge l'enregistrement dynamique de clients, utilisez l'ID client mcp-client pré-enregistré.

Voir OAuth HarnessID pour un serveur MCP auto-hébergé pour la liste de contrôle Keycloak QA et les commandes de validation.

Mode multi-utilisateurs

Définissez HARNESS_MCP_MODE=multi-user pour les déploiements HTTP partagés où chaque client s'authentifie en tant qu'utilisateur Harness différent. Dans ce mode :

• HARNESS_API_KEY ne doit pas être défini dans la configuration du serveur — le serveur ne détient aucune information d'identification Harness.
• Chaque session doit fournir x-harness-api-key sur la requête initialize. x-harness-account-id n'est requis que lorsque la clé API n'intègre pas de segment de compte.
• Les sessions peuvent également fournir les en-têtes x-harness-org et x-harness-project pour définir la portée par défaut de cette session.
• La clé API Harness circule dans chaque appel API Harness pour cette session, donc la piste d'audit dans Harness reflète l'utilisateur réel.
• HARNESS_MCP_AUTH_TOKEN est indépendant et peut toujours être utilisé comme couche de contrôle de transport supplémentaire.

# 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 contrôle la validation de l'en-tête Host pour la protection contre le rebinding DNS, et CORS limite les origines des navigateurs. Ni l'un ni l'autre n'est une authentification ; utilisez HARNESS_MCP_AUTH_TOKEN ou une passerelle/proxy inverse authentifié pour le contrôle d'accès.

Configuration du client

Remarque : HARNESS_ORG et HARNESS_PROJECT sont facultatifs. Ils définissent l'ID d'organisation et l'ID de projet utilisés lorsqu'ils ne sont pas spécifiés par appel d'outil. Les agents peuvent découvrir dynamiquement les organisations et les projets en utilisant harness_list(resource_type="organization") et harness_list(resource_type="project"). Les noms obsolètes HARNESS_DEFAULT_ORG_ID et HARNESS_DEFAULT_PROJECT_ID sont toujours acceptés pour la compatibilité ascendante.

MCP Harness hébergé

Harness prend également en charge un point de terminaison MCP hébergé pour les comptes qui ont le service géré activé. Cela est utile lorsque vous souhaitez un point de terminaison MCP distant partagé au lieu d'exécuter npx harness-mcp-v2 ou d'auto-héberger le transport HTTP vous-même.

Important : L'authentification MCP hébergée utilise Harness Platform OAuth. Elle n'utilise pas HARNESS_API_KEY dans la configuration client. La disponibilité du MCP hébergé est configurée par compte Harness. Vous devrez donc collaborer avec le Harness Support pour activer/configurer ce paramètre avant de l'utiliser.

Le point de terminaison hébergé https://mcp.harness.io/mcp est un service géré. La configuration MCP côté client dans Claude, Cursor ou Cowork ne peut pas remplacer l'environnement Harness vers lequel il route. Pour Harness0 ou un autre environnement SaaS Harness privé, demandez au Harness Support d'activer/configurer le MCP hébergé pour cet environnement, ou exécutez le serveur local/auto-hébergé et définissez HARNESS_BASE_URL sur l'hôte Harness cible.

Exemple de MCP hébergé :

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

Exemple avec des entrées hébergées et locales :

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

Dépannage de npx ENOENT ou node: No such file or directory

Il s'agit d'un échec de lancement du processus client, et non d'un échec d'authentification Harness. Le serveur MCP n'a pas encore démarré, donc modifier HARNESS_API_KEY n'affectera pas spawn npx ENOENT.

Les applications GUI (Cursor, Claude Desktop, Devin Desktop, VS Code) n'héritent pas toujours du PATH de votre shell, elles peuvent donc ne pas trouver npx ou node après un rechargement de configuration. Corrigez cela en utilisant des chemins absolus et en définissant explicitement PATH dans le bloc env :

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

Trouvez vos chemins avec which npx et which node dans un terminal, puis assurez-vous que le répertoire contenant node est inclus dans la valeur PATH ci-dessus. Emplacements courants :

• Homebrew (macOS) : /opt/homebrew/bin/npx
• nvm : ~/.nvm/versions/node/v20.x.x/bin/npx (exécutez nvm which current pour trouver le chemin exact)
• Node système : /usr/local/bin/npx

Claude Desktop (claude_desktop_config.json)

npx (installation zéro)

{
  "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 (installation locale)

npm install -g harness-mcp-v2

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

Claude Code (via claude mcp add)

npx (installation zéro)

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

node (installation locale)

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

Ensuite, définissez HARNESS_API_KEY dans votre environnement ou dans le fichier .env.

Cursor (.cursor/mcp.json)

npx (installation zéro, recommandé pour les configurations Cursor locales)

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

Exécutez which npx dans un terminal et utilisez ce chemin complet pour command ; incluez le répertoire de which node au début de PATH.

node (installation locale)

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

Exécutez which harness-mcp-v2 après npm install -g harness-mcp-v2 et utilisez ce chemin complet pour command ; incluez le répertoire de which node au début de PATH.

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

npx (installation zéro)

{
  "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 (installation locale)

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

Vous utilisez une compilation locale à partir des sources ?

Remplacez la commande par le chemin vers votre index.js compilé :

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

Passerelle MCP

Le serveur MCP Harness est entièrement compatible avec les passerelles MCP — des proxys inverses qui fournissent une authentification centralisée, une gouvernance, un routage des outils et une observabilité sur plusieurs serveurs MCP. Comme le serveur implémente le protocole MCP standard avec les transports stdio et HTTP, il fonctionne derrière toute passerelle conforme MCP sans modification de code.

Pourquoi utiliser une passerelle ?

• Gestion centralisée des identifiants — pas de clés API dans les configurations d'agents
• Gouvernance et journalisation d'audit pour tous les appels d'outils à travers les équipes
• Point de terminaison unique pour les agents au lieu de N connexions à N serveurs MCP
• Contrôle d'accès — restreignez les équipes qui peuvent utiliser quels outils

Passerelle MCP Docker

Enregistrez le serveur dans votre configuration de passerelle MCP Docker :

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

Portkey

Ajoutez le serveur MCP Harness à votre Passerelle MCP Portkey pour la gouvernance d'entreprise, le suivi des coûts et le routage multi-LLM :

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

LiteLLM

Ajoutez à votre configuration de proxy LiteLLM :

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

Passerelle IA Envoy

Le serveur fonctionne avec le support MCP de la passerelle IA Envoy via le transport HTTP :

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

Ensuite, configurez Envoy pour router vers http://localhost:8080/mcp comme backend MCP en amont.

Kong

Utilisez le plugin Proxy MCP IA de Kong pour exposer le serveur MCP Harness via votre infrastructure de passerelle Kong existante.

Autres passerelles

Toute passerelle qui prend en charge la spécification MCP (Microsoft MCP Gateway, IBM ContextForge, Cloudflare Workers, etc.) peut servir de proxy pour ce serveur. Pour les passerelles basées sur stdio, utilisez le transport par défaut. Pour les passerelles basées sur HTTP, démarrez le serveur avec le transport http et pointez la passerelle vers le point de terminaison /mcp.

Docker

Compilez et exécutez le serveur en tant que conteneur Docker :

# Build the image
pnpm docker:build

# Run with your .env file
pnpm docker:run

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

Le conteneur s'exécute en mode HTTP sur le port 3000 par défaut avec une vérification de santé intégrée.

Kubernetes

Déployez sur un cluster Kubernetes à l'aide des manifests fournis :

# 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

Le déploiement exécute 2 réplicas avec des sondes de préparation/liveness, des limites de ressources et un contexte de sécurité non-root. Le Service expose le port 80 en interne (ciblant le port 3000 du conteneur).

Configuration

Le serveur charge automatiquement les variables d'environnement à partir d'un fichier .env dans la racine du projet s'il existe. Copiez .env.example vers .env et remplissez vos valeurs. Les variables d'environnement peuvent également être définies via votre shell ou la configuration du client MCP.

Variable	Requis	Défaut	Description
HARNESS_MCP_MODE	Non	single-user	Mode de déploiement : single-user (clé API partagée), multi-user (HTTP avec clés API par session) ou oauth (HTTP avec validation du jeton d'accès HarnessID)
HARNESS_API_KEY	Oui*	--	Jeton d'accès personnel Harness ou jeton de compte de service. Requis en mode single-user. Ne doit PAS être défini en mode multi-user ou oauth, où chaque session apporte sa propre identifiant
HARNESS_ACCOUNT_ID	Non	(du PAT/SAT)	Identifiant de compte Harness. Auto-extrait des jetons PAT/SAT en mode mono-utilisateur ; les sessions multi-utilisateurs peuvent fournir le leur via x-harness-account-id lorsque la clé API n'en intègre pas un
HARNESS_BASE_URL	Non	https://app.harness.io (https://mcp.harness.io/cli en mode OAuth)	URL de base API/UI Harness. Le mode OAuth passe par le proxy MCP hébergé /cli par défaut ; les autres modes utilisent directement l'API SaaS Harness
HARNESS_MCP_OAUTH_ISSUER	Non	https://id.harness.io/idp/realms/HarnessIDP	Émetteur HarnessID comparé exactement à la revendication iss du jeton d'accès
HARNESS_MCP_OAUTH_RESOURCE	Non	https://mcp.harness.io/mcp	URL MCP canonique publique publiée comme identifiant de ressource RFC 9728
HARNESS_MCP_OAUTH_JWKS_URI	Non	<issuer>/protocol/openid-connect/certs	Point de terminaison JWKS HarnessID utilisé pour valider les signatures RS256 des jetons d'accès
HARNESS_MCP_OAUTH_CLIENT_ID	Non	mcp-client	Client HarnessID auquel le jeton d'accès doit être émis, vérifié contre la revendication azp du jeton
HARNESS_MCP_OAUTH_ACCOUNT_CLAIM	Non	account_id	Revendication du jeton d'accès portant l'ID de compte Harness, renseignée par le scope HarnessID organization
HARNESS_MCP_OAUTH_SCOPES	Non	openid profile email organization	Scopes séparés par des espaces annoncés dans les métadonnées de ressource protégée RFC 9728
HARNESS_FME_API_KEY	Non	--	Identifiant optionnel mono-utilisateur/auto-hébergé FME/Split Admin utilisé pour les ressources fme_ uniquement en mode hérité (workspace_id). Le FME hérité est indisponible en mode OAuth, donc les jetons HarnessID ne sont jamais envoyés à api.split.io ; utilisez le scope natif Harness org_id+project_id à la place. Ne doit pas être défini en mode multi-user ou oauth
HARNESS_FME_BASE_URL	Non	https://api.split.io	URL de base de l'API Admin Split/FME utilisée par les ressources fme_ uniquement en mode hérité (workspace_id). Les URL HTTP nécessitent HARNESS_ALLOW_HTTP=true pour le développement local. Le mode natif Harness (org_id+project_id) ignore ce paramètre et utilise le standard HARNESS_API_KEY/HARNESS_BASE_URL à la place
HARNESS_ORG	Non	--	ID d'organisation. Utilisé lorsque org_id n'est pas spécifié par appel d'outil. S'il est omis, org_id doit être fourni explicitement. Les agents peuvent aussi découvrir les orgs dynamiquement via harness_list(resource_type="organization")
HARNESS_PROJECT	Non	--	ID de projet. Utilisé lorsque project_id n'est pas spécifié par appel d'outil. Les agents peuvent aussi découvrir les projets dynamiquement via harness_list(resource_type="project")
HARNESS_API_TIMEOUT_MS	Non	30000	Délai d'expiration des requêtes HTTP en millisecondes
HARNESS_MAX_RETRIES	Non	3	Nombre de tentatives pour les échecs transitoires (429, 5xx)
HARNESS_MAX_BODY_SIZE_MB	Non	10	Taille maximale du corps de requête HTTP en Mo pour le transport http
HARNESS_RATE_LIMIT_RPS	Non	10	Limitation des requêtes côté client (requêtes par seconde) vers les API Harness
LOG_LEVEL	Non	info	Niveau de journalisation : debug, info, warn, error
HARNESS_TOOLSETS	Non	(défauts)	Liste d'outils séparée par des virgules. Vide charge les outils par défaut. Prend en charge +name pour inclure explicitement les outils optionnels et -name pour retirer les défauts (voir Filtrage des outils)
HARNESS_READ_ONLY	Non	false	Bloquer toutes les opérations de mutation (créer, mettre à jour, supprimer, exécuter). Seuls lister et obtenir sont autorisés. Utile pour les environnements partagés/démo
HARNESS_AUTO_APPROVE_RISK	Non	none	Seuil d'approbation automatique basé sur le risque pour les flux autonomes. Les opérations à ce risque ou en dessous se poursuivent sans confirmation. Valeurs : none, low_write, medium_write, high_write, all. Voir Élicitation
HARNESS_SKIP_ELICITATION	Non	false	Obsolète — utilisez HARNESS_AUTO_APPROVE_RISK=all à la place. Conservé pour la rétrocompatibilité
HARNESS_ALLOW_HTTP	Non	false	Autoriser les HARNESS_BASE_URL non-HTTPS. Par défaut, le serveur impose HTTPS pour la sécurité. Définissez sur true uniquement pour le développement local contre une instance Harness sans TLS
HARNESS_PIPELINE_VERSION	Non	0	(Alpha) Version YAML du pipeline. 0 charge le type de ressource pipeline et exclut pipeline_v1 ; 1 charge pipeline_v1 et exclut pipeline. Les sessions HTTP peuvent le remplacer à l'initialisation avec x-harness-pipeline-version: 0 ou 1
HARNESS_MCP_ALLOWED_HOSTS	Non	--	Noms d'hôtes séparés par des virgules autorisés par la validation de l'en-tête Host du transport HTTP. mcp.harness.io est autorisé par défaut pour les liaisons localhost ; ajoutez ici les domaines proxy/personnalisés
HARNESS_MCP_AUTH_TOKEN	Non	--	Jeton Bearer statique requis sur les routes HTTP /mcp lorsqu'il est défini. Requis par défaut pour les liaisons mono-utilisateur et multi-utilisateurs non-bouclage. Doit être non défini en mode oauth
HARNESS_MCP_ALLOW_UNAUTHENTICATED_HTTP	Non	false	Autoriser explicitement le transport HTTP non authentifié sur les liaisons non-bouclage. Utiliser uniquement derrière un autre contrôle authentifié
HARNESS_MCP_TRUST_PROXY	Non	0	Nombre de sauts de proxy inverse / équilibreur de charge à considérer pour la résolution de l'IP client (Express trust proxy). Définissez le nombre de proxys devant le serveur pour que la limitation par IP s'applique au vrai client plutôt qu'au pair de socket du proxy
HARNESS_MCP_LOG_FILE	Non	~/.claude/harness-mcp.log	Fichier utilisé pour les diagnostics de déconnexion/crash stdio lorsque stderr peut ne plus être disponible
HARNESS_LOG_UNSAFE_BODIES	Non	false	Inclure les corps de requête/réponse bruts dans les journaux. Désactivé par défaut car les corps peuvent contenir des secrets ; activez uniquement pour le débogage local
HARNESS_AUDIT_FILE	Non	--	Ajouter les événements d'audit à un fichier JSON délimité par des nouvelles lignes pour une collecte locale durable
HARNESS_AUDIT_WEBHOOK_URL	Non	--	Point de terminaison HTTPS recevant les événements d'audit par lots. Les URL HTTP nécessitent HARNESS_ALLOW_HTTP=true pour le développement local
HARNESS_AUDIT_WEBHOOK_TOKEN	Non	--	Jeton Bearer optionnel envoyé au webhook d'audit
HARNESS_AUDIT_WEBHOOK_BATCH_SIZE	Non	10	Nombre d'événements d'audit à regrouper avant le vidage du webhook
HARNESS_AUDIT_WEBHOOK_FLUSH_MS	Non	5000	Durée maximale de conservation des événements d’audit avant le vidage webhook
OTEL_EXPORTER_OTLP_ENDPOINT	Non	--	Active les spans d’audit OpenTelemetry lorsque les packages OpenTelemetry optionnels sont installés
HARNESS_SEARCH_PROVIDER	Non	local	Backend de recherche sémantique : local (embeddings ONNX en processus, par défaut), remote (service de recherche externe via HTTP, requis pour le mode multi-utilisateur), ou none (désactiver la recherche sémantique, revenir au scatter-gather par mots-clés uniquement). Utilisez none dans les environnements isolés ou lorsque le chargement du modèle au démarrage n’est pas souhaitable
HARNESS_SEARCH_SERVICE_URL	Non	--	URL de base du service de recherche distant lorsque HARNESS_SEARCH_PROVIDER=remote (par ex. http://search-svc:8080). Requis lors de l’utilisation du fournisseur remote
HARNESS_SEARCH_SERVICE_HEADERS	Non	--	Objet JSON d’en-têtes envoyés avec chaque requête au service de recherche distant. Prend en charge tout schéma d’authentification : {"Authorization":"Bearer tok"}, {"x-api-key":"key"}, ou plusieurs en-têtes internes de service à service
HARNESS_HF_CACHE_DIR	Non	/tmp/hf-cache	Répertoire pour le cache du modèle @huggingface/transformers utilisé par le fournisseur de recherche local. L’image Docker pré-intègre le modèle dans /app/.cache/hf pour éviter les téléchargements à l’exécution. Définissez un chemin de volume persistant dans les déploiements de production
HARNESS_DIAGNOSE_LOG_FETCH_CONCURRENCY	Non	3	Nombre maximal de téléchargements simultanés de blobs de journaux émis par harness_diagnose lors de la récupération des journaux pour les étapes échouées. Augmentez uniquement si la latence de diagnostic est dominée par le temps d’horloge mural de récupération des journaux et que le pod dispose d’une marge mémoire suffisante

Recherche sémantique

harness_search utilise le routage sémantique pour réduire les appels API de type scatter-gather avant de les répartir vers Harness. Trois fournisseurs de recherche sont disponibles :

Fournisseur	Quand l'utiliser
local (par défaut)	Mode stdio mono-utilisateur. Exécute all-MiniLM-L6-v2 en processus via @huggingface/transformers. Télécharge un modèle d'environ 23 Mo lors de la première utilisation ; les démarrages suivants utilisent le cache.
remote	Mode HTTP multi-utilisateurs (hébergé par Harness). Délègue l'embedding et la récupération à un service de recherche externe. L'isolation des locataires est appliquée via tenant_id — les connaissances et documents statiques utilisent global, les données d'entités par compte utilisent l'ID du compte.
none	Désactive entièrement la recherche sémantique ; revient à une recherche par mots-clés de type scatter-gather sur tous les types de ressources.

Configuration du fournisseur distant :

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

Test du fournisseur distant en local avec le service stub inclus (aucune dépendance externe) :

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

Le stub (stub-search-service.py) implémente le même contrat /v1/health, /v1/ingest et /v1/search que le service de recherche en production. Il utilise un simple embedding de type sac de caractères, donc aucun téléchargement de modèle n'est requis — les résultats sont sémantiquement plausibles mais pas de qualité production.

Application stricte de HTTPS

HARNESS_BASE_URL doit utiliser HTTPS par défaut. Si vous définissez une URL non-HTTPS (par exemple http://localhost:8080), le serveur refusera de démarrer avec :

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

Journalisation d'audit

Toutes les opérations API Harness distribuées par le registre (list, get, create, update, delete et execute) émettent des événements d'audit structurés lorsque des récepteurs d'audit sont configurés. Les événements de mutation incluent le chemin de confirmation utilisé par l'élicitation ou l'approbation automatique lorsqu'un contexte de confirmation est présent ; les événements de lecture omettent actuellement les métadonnées de confirmation. Les outils de découverte de métadonnées locales et de schéma qui contournent le registre, tels que harness_describe et harness_schema, ne font pas partie de ce flux d'audit. Un récepteur stderr est enregistré par défaut mais passe par le journaliseur normal et obéit à LOG_LEVEL ; configurez des récepteurs de fichiers ou de webhooks pour une collecte d'audit durable :

• HARNESS_AUDIT_FILE ajoute des événements JSON délimités par des sauts de ligne pour la collecte locale.
• HARNESS_AUDIT_WEBHOOK_URL envoie des lots { "events": [...] } à un webhook HTTPS, éventuellement avec HARNESS_AUDIT_WEBHOOK_TOKEN. Les lots échoués sont remis en file d'attente avec une capacité limitée et finalement abandonnés avec un avertissement plutôt que de bloquer l'exécution des outils.
• OTEL_EXPORTER_OTLP_ENDPOINT active les spans d'audit lorsque les dépendances optionnelles OpenTelemetry sont installées. Le récepteur réutilise un fournisseur de traceur existant lorsqu'il est enregistré, sinon il initialise un exportateur OTLP autonome.

Chaque événement inclut le nom de l'outil, le type de ressource, l'opération, les identifiants, l'horodatage, le risque, le résultat, la méthode/le chemin HTTP, la durée et la méthode de confirmation lorsque applicable. Les récepteurs d'audit sont une télémétrie au mieux ; les problèmes de livraison sont journalisés et ne rejouent ni ne modifient jamais l'opération API Harness sous-jacente. Pour les détails de configuration OTel et les attributs de spans, voir specs/005-otel-audit-sink.md.

Référence des outils

Le serveur expose 11 outils MCP. La plupart des outils API acceptent org_id et project_id comme remplacements optionnels — s'ils sont omis, ils reviennent à HARNESS_ORG et HARNESS_PROJECT. harness_describe est uniquement des métadonnées locales et n'utilise pas la portée org/projet.

Prise en charge des URL : La plupart des outils orientés API acceptent un paramètre url — collez une URL de l'interface Harness et le serveur extrait automatiquement l'org, le projet, le type de ressource, l'ID de ressource, l'ID de pipeline et l'ID d'exécution. harness_describe n'accepte pas url.

Prise en charge de la portée : Les types de ressources avec des variantes compte/org/projet exposent supportedScopes dans harness_describe. Passez resource_scope lorsque vous avez besoin d'un niveau spécifique :

• resource_scope: "account" envoie uniquement accountIdentifier.
• resource_scope: "org" envoie accountIdentifier et orgIdentifier.
• resource_scope: "project" envoie les identifiants de compte, d'org et de projet.

Les ressources multi-portées actuelles incluent connector, service, environment, infrastructure, secret, file_store, template, policy et policy_set. Si resource_scope est omis, le registre utilise la portée par défaut de la ressource et les valeurs par défaut configurées, sauf que les ressources marquées comme portée facultative peuvent omettre org/projet sauf si explicitement passés. Les URL Harness peuvent également définir la portée automatiquement lorsque le chemin contient un contexte au niveau du compte ou du projet.

Sortie structurée : Chaque outil déclare un outputSchema MCP. harness_list normalise les réponses Harness de type liste en contenu structuré en forme d'objet afin que les clients stricts puissent le valider : les tableaux de niveau supérieur deviennent { "items": [...], "total": <count>, "page": <page> }, et les clés d'encapsulation courantes telles que content, data, body, objects ou features sont remontées vers items lorsque nécessaire. La réponse texte contient toujours la charge utile JSON compacte renvoyée à tous les clients.

Outil	Description
harness_describe	Découvrez les types de ressources, opérations et champs disponibles. Aucun appel API — renvoie les métadonnées du registre local.
harness_schema	Récupérez les définitions exactes de schémas YAML/JSON et des exemples pour créer/mettre à jour des ressources. Les schémas de pipelines/modèles sont inclus ; les schémas de connecteurs, environnements, services, secrets et infrastructures sont des schémas d'entités sensibles au contexte, récupérés à partir de snapshots inclus ou de NG /yaml-schema ; les schémas release_process et release_activity sont récupérés en direct depuis RMG /api/yamlSchema. Prend en charge l'exploration approfondie via path.
harness_list	Liste les ressources d'un type donné avec filtrage, recherche et pagination.
harness_get	Récupère une ressource unique par son identifiant.
harness_create	Crée une nouvelle ressource. Prend en charge les pipelines en ligne et distants (basés sur Git). Demande une confirmation à l'utilisateur via elicitation.
harness_update	Met à jour une ressource existante. Prend en charge les pipelines en ligne et distants (basés sur Git). Demande une confirmation à l'utilisateur via elicitation.
harness_delete	Supprime une ressource. Demande une confirmation à l'utilisateur via elicitation. Destructif.
harness_execute	Exécute une action sur une ressource (exécuter/relancer un pipeline, importer un pipeline depuis Git, basculer un indicateur, synchroniser une application). Demande une confirmation à l'utilisateur via elicitation. Pour les exécutions de pipelines, utilisez le flux de travail d'entrées d'exécution ci-dessous (prend en charge l'expansion abrégée branch/tag/pr_number/commit_sha).
harness_search	Recherche dans les types de ressources Harness avec une seule requête. Utilise le routage sémantique (embeddings ONNX locaux all-MiniLM-L6-v2, 384 dimensions) pour prédire les types de ressources pertinents à partir d'un corpus knowledge indexé au démarrage — réduisant généralement de ~163 types à 1–8 avant la collecte dispersée. Replie sur une collecte dispersée par mots-clés complète lorsque la confiance sémantique est faible. La réponse inclut semantic_routed et types_skipped lorsque le routage est déclenché. Voir docs/search-guidelines.md pour savoir comment rendre de nouveaux types de ressources découvrables.
harness_diagnose	Diagnostique les ressources pipeline, connector, delegate et gitops_application (alias : execution -> pipeline, gitops_app -> gitops_application). Pour les pipelines, renvoie les temps des étapes et les détails des échecs ; pour les connecteurs/délégués/applications GitOps, renvoie des signaux ciblés de santé et de dépannage.
harness_status	Obtenez un tableau de bord de santé de projet en temps réel — exécutions récentes, taux d'échec et liens profonds.

Flux de travail de recherche de schéma

Utilisez harness_schema avant de créer ou mettre à jour des ressources basées sur YAML afin que les agents puissent copier les noms de champs et contraintes exacts au lieu de deviner à partir du texte.

• Les schémas inclus incluent pipeline, template, trigger, pipeline_v1, template_v1, inputSet_v1, overlayInputSet_v1 et agent-pipeline.
• Les schémas d'entités incluent connector, environment, service, secret et infrastructure. Ils sont sensibles au contexte (account, org ou project) et nécessitent org_id/project_id lorsque le contexte sélectionné l'exige.
• Les définitions Release Management (release_process, release_activity) récupèrent les schémas JSON en direct depuis RMG /api/yamlSchema (non inclus). Passez scope, org_id et project_id lors du ciblage d'une organisation ou d'un projet.
• Les snapshots d'entités fournis sont utilisés en premier lorsqu'ils correspondent au compte d'exécution ; sinon, l'outil revient à l'API NG /yaml-schema de Harness et met en cache le résultat.
• Omettez path pour un résumé des champs/sections, puis passez un path séparé par des points pour inspecter une définition imbriquée.

Exemples :

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

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

Les mainteneurs peuvent actualiser les snapshots d'entités fournis avec pnpm sync-entity-schemas lorsque les schémas YAML d'entités Harness changent.

Exemples d'outils

Découvrez quelles ressources sont disponibles :

{ "resource_type": "pipeline" }

Listez les organisations du compte :

{ "resource_type": "organization" }

Listez les projets d'une organisation :

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

Listez les pipelines d'un projet :

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

Récupérez un service spécifique :

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

Exécutez un pipeline :

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

Basculez un indicateur de fonctionnalité :

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

Recherchez dans tous les types de ressources :

{ "query": "payment-service" }

Diagnostiquez une exécution par ID (mode résumé — par défaut) :

{ "execution_id": "abc123XYZ" }

Diagnostiquez à partir d'une URL Harness :

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

Diagnostiquez la connectivité d'un connecteur :

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

Diagnostiquez la santé d'un délégué :

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

Diagnostiquez une application GitOps (avec options) :

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

Obtenez le dernier rapport d'exécution d'un pipeline :

{ "pipeline_id": "my-pipeline" }

Mode diagnostic complet avec YAML et journaux d'étapes en échec :

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

Mode résumé avec journaux activés (le meilleur des deux) :

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

Obtenez l'état de santé du projet :

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

Listez les schémas de base de données filtrés par type de migration :

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

Listez les instances de base de données pour un schéma :

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

Obtenez le pipeline de création LLM résolu pour un schéma et une instance :

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

Listez les noms d'objets de snapshot (par exemple, les tables) pour une instance de schéma :

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

Obtenez les métadonnées complètes de snapshot pour des objets nommés spécifiques :

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

Flux de travail d'exécution de pipeline (recommandé)

Pour les pipelines v0, utilisez cette séquence pour réduire les erreurs d'entrées au moment de l'exécution :

1. Découvrez les entrées d'exécution requises

• harness_get(resource_type="runtime_input_template", resource_id="<pipeline_id>")
• Le modèle renvoyé montre les espaces réservés <+input> qui nécessitent des valeurs.

2. Choisissez la stratégie d'entrées

• Variables simples : passez des paires clé-valeur plates inputs (par exemple {"branch":"main","env":"prod"}).

• Entrées complexes/structurées : utilisez input_set_ids (les blocs de codebase/build CI et les entrées de modèles imbriquées sont mieux gérées de cette façon).

• Clés abrégées de codebase CI (exécution de pipeline uniquement) :

  Clé abrégée	Structure développée
  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>

• Contrainte : l'expansion abrégée est ignorée lorsque inputs.build est déjà présent (le build explicite gagne).

3. Exécutez l'exécution

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

• Pour les pipelines basés sur Git dont le YAML doit être chargé depuis une branche non par défaut, passez params.pipeline_branch (envoyé à Harness comme branch). Ce sélecteur de définition explicite a priorité sur l'alias params.branch. inputs.branch sélectionne indépendamment la branche de codebase CI :

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

4. Optionnel : combinez les deux

• Utilisez input_set_ids pour la forme de base et inputs pour les remplacements simples.

Pour les pipelines v1 :

1. Récupérez harness_get(resource_type="runtime_input_template_v1", resource_id="<pipeline_id>"). Pour les pipelines basés sur Git, passez branch_name, connector_ref et repo_name via params.
2. Utilisez chaque inputs[].details.name renvoyé comme clé de niveau supérieur dans harness_execute.inputs.
3. Exécutez harness_execute(resource_type="pipeline_v1", action="run", resource_id="<pipeline_id>", inputs={...}). Le serveur encapsule ces valeurs sous une racine YAML inputs: et envoie le corps inputs_yaml de l'API. Si des champs obligatoires ne sont pas résolus, l'outil renvoie une erreur de pré-vol avec les clés attendues et les ensembles d'entrée suggérés. Vous pouvez inspecter les mappages de raccourcis disponibles avec harness_describe(resource_type="pipeline") (executeActions.run.inputShorthands).

Exécution dynamique de pipeline

Utilisez pipeline_dynamic_execution.run lorsqu'un agent ou un système externe génère le YAML complet du pipeline v0 à l'exécution et doit l'exécuter contre une coquille de pipeline Harness existante. Cela ne remplace pas le pipeline.run normal : le pipeline v0 enregistré doit déjà exister, les paramètres Allow Dynamic Execution au niveau du compte et du pipeline doivent être activés, et l'appelant doit disposer des autorisations Edit et Execute sur le 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
  }
}

Contraintes :

• body doit être un objet avec un champ yaml. Les corps de chaîne bruts sont rejetés par le schéma public harness_execute.
• body.yaml peut être une chaîne YAML ou un objet de pipeline JSON ; le JSON est sérialisé en YAML avant la requête.
• Les espaces réservés <+input> d'exécution ne sont pas résolus par cette API. Soumettez un YAML entièrement résolu.
• Les ensembles d'entrée, l'exécution sélective d'étapes, les nouvelles tentatives et les déclencheurs ne sont pas pris en charge par le point de terminaison d'exécution dynamique.
• L'action est high_write et utilise le chemin normal de confirmation/approbation automatique. La réponse projette l'enveloppe API vers { "execution_id": "...", "status": "..." } et inclut un lien d'exécution openInHarness lorsque les données de portée sont disponibles.

Si Harness rejette l'exécution comme non activée, vérifiez à la fois le paramètre Allow Dynamic Execution au niveau du compte et l'interrupteur au niveau du pipeline sous Pipeline -> Advanced Options -> Dynamic Execution Settings.

Analyse médico-légale des entrées d'exécution

Utilisez execution_inputs après une exécution pour inspecter le YAML d'entrée fusionné qui a produit une exécution spécifique. Cela est utile lorsqu'un échec dépend de la fusion d'ensembles d'entrée, de branches d'ensembles d'entrée adossées à Git, ou de valeurs de déclencheur/d'exécution difficiles à reconstruire à partir de la page d'exécution seule.

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

La réponse get est projetée vers :

• executionId - l'ID d'exécution du plan depuis resource_id.
• inputSetYaml - YAML d'entrée d'exécution fusionné utilisé pour l'exécution, ou null.
• inputSetTemplateYaml - modèle d'entrée au moment de l'exécution, ou null.
• resolvedYaml - YAML résolu par expression lorsque resolve_expressions=true, sinon généralement null.
• inputSetDetails - ensembles d'entrée enregistrés contributifs sous forme de paires { identifier, name }.
• inputSetBranchName - branche source pour les ensembles d'entrée adossés à Git, ou null.

execution_inputs est en lecture seule et à risque de lecture. Si resolve_expressions est omis, le serveur omet les paramètres de requête API et Harness utilise son mode de résolution UNKNOWN par défaut.

Mode d'attente d'exécution de pipeline

Pour pipeline.run, pipeline.retry et pipeline_v1.run, passez wait: true pour laisser le serveur interroger jusqu'à ce que l'exécution atteigne un statut terminal. Cela maintient le lancement d'un pipeline et la vérification de statut dans un seul appel d'outil au lieu de demander au client ou au LLM d'exécuter une boucle d'interrogation.

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

Comportement du mode d'attente :

• Le délai d'attente par défaut est de 600 secondes ; la plage autorisée est de 10 secondes à 7200 secondes.
• L'intervalle d'interrogation initial est par défaut de 3 secondes, avec un backoff de 1,5x, et plafonné à 30 secondes.
• En cas de succès ou d'échec, la réponse inclut des champs tels que execution_id, execution_status, execution_terminal, execution_elapsed_ms et execution_poll_count.
• Si le délai d'attente expire, le déclencheur d'origine a toujours réussi ; la réponse inclut execution_timed_out: true et _wait.hint avec le dernier statut observé.
• Si l'interrogation échoue après la réussite du déclencheur, la réponse inclut _wait.error et une indication de re-vérification. Ne relancez pas aveuglément le pipeline à moins d'avoir confirmé que la première exécution n'est pas en cours.
• Les statuts terminaux en échec incluent _diagnose_hint pointant vers harness_diagnose(resource_type="execution", options={execution_id: "..."}).

Demandez à l'agent DevOps IA de créer un pipeline :

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

Mettez à jour un service en langage naturel :

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

Modes de stockage de pipeline

Les pipelines Harness peuvent être stockés de trois manières :

Mode	Description	Quand l'utiliser
Inline	YAML de pipeline stocké dans Harness	Par défaut. Configuration la plus simple, aucun Git requis.
Remote (Git externe)	YAML de pipeline stocké dans GitHub, GitLab, Bitbucket, etc.	Équipes utilisant le pipeline-as-code adossé à Git avec un fournisseur externe.
Remote (Harness Code)	YAML de pipeline stocké dans un dépôt Harness Code	Équipes utilisant l'hébergement Git intégré de Harness.

Créer un pipeline inline (par défaut) :

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

Créer un pipeline distant (Git externe — par ex. 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"
  }
}

Créer un pipeline distant (Harness Code — aucun connecteur requis) :

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

Mettre à jour un pipeline distant :

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

Importer un pipeline depuis un dépôt Git externe :

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

Importer un pipeline depuis un dépôt Harness Code :

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

Créer un connecteur :

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

Supprimer un déclencheur :

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

Lister les ensembles d'entrée pour un pipeline :

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

Obtenir un ensemble d'entrée spécifique :

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

Créer un ensemble d'entrée :

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

Mettre à jour un ensemble d'entrée :

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

Supprimer un ensemble d'entrée :

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

Types de ressources

259 types de ressources organisés dans 42 ensembles d'outils. Chaque type de ressource prend en charge un sous-ensemble d'opérations CRUD et des actions d'exécution facultatives.

Plateforme

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
organization	x	x	x	x	x
project	x	x	x	x	x

Pipelines

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
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

Les deux types de ressources YAML de pipeline sont disponibles lorsque l'ensemble d'outils pipelines est activé. HARNESS_PIPELINE_VERSION et l'en-tête d'initialisation HTTP x-harness-pipeline-version sélectionnent la préférence de version par défaut ; ils ne masquent pas l'autre version.

Agents IA

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
agent	x	x	x	x	x
agent_run	x

Services

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
service	x	x	x	x	x

Environnements

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
environment	x	x	x	x	x	move_configs

Connecteurs

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
connector	x	x	x	x	x	test_connection
connector_catalogue	x

Infrastructure

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
infrastructure	x	x	x	x	x	move_configs

Secrets

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
secret	x	x

Journaux d'exécution

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
execution_log		x

Piste d'audit

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
audit_event	x	x

Délégués

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
delegate	x	x
delegate_token	x	x	x		x	revoke, get_delegates

Dépôts de code

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
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

La création de commit valide une ou plusieurs actions de fichier directement via l'API Harness Code sans clonage. Passez body.title, body.branch et body.actions ; chaque action est CREATE, UPDATE, DELETE ou MOVE, et UPDATE nécessite le SHA de blob actuel.

La liste de file_content renvoie chaque chemin à une référence ; get renvoie le contenu du fichier ou du répertoire (omettez ou passez un path vide pour la racine du dépôt ; les chemins imbriqués conservent les barres obliques). Omettez git_ref pour utiliser la branche par défaut du dépôt — ne devinez pas main.

Registres d'artefacts

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
registry	x	x
artifact	x
artifact_version	x
artifact_file	x

File Store

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
file_store	x	x	x	x	x	list_children

file_store gère les fichiers et dossiers du File Store Harness via les outils génériques. Il prend en charge les portées compte, organisation et projet ; transmettez resource_scope="account"|"org"|"project" ou collez une URL du File Store Harness afin que le serveur puisse dériver la portée et les identifiants.

Appels courants :

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

Contraintes du corps multipart :

• La création/mise à jour accepte le JSON body, puis le convertit en multipart/form-data pour /ng/api/file-store.
• name, type (FILE ou FOLDER) et parent_identifier sont requis ; utilisez le littéral "Root" uniquement pour la racine de la portée sélectionnée.
• La création de FILE nécessite exactement un élément parmi content (chaîne UTF-8) ou content_base64 (base64 valide non vide). La mise à jour de FILE peut omettre le contenu pour les mises à jour de métadonnées uniquement, ou fournir exactement un champ de contenu pour remplacer le contenu.
• La création/mise à jour de FOLDER doit omettre content et content_base64.
• Le file_usage facultatif doit être MANIFEST_FILE, CONFIG ou SCRIPT ; les métadonnées scalaires facultatives telles que description, mime_type, path et tags doivent être des chaînes.
• Le contenu téléversé est plafonné à 100 Mo. Les invites de confirmation masquent les aperçus de content, content_base64 et contentBase64 avant la sollicitation.

list_children accepte soit la forme abrégée (resource_id plus params.folder_name, ou params.file_store_id/params.folder_identifier plus params.folder_name) soit un FileStoreNode complet body avec identifier, name et type: "FOLDER". Les corps complets utilisent la notation camelCase Harness parentIdentifier ; la forme abrégée peut utiliser params.parent_identifier.

Modèles

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
template	x	x	x	x	x

Les opérations sur les modèles utilisent les chemins du service Template Harness (/template/api/templates...). La création et la mise à jour nécessitent la chaîne YAML complète du modèle dans body.template_yaml ou body.yaml ; version_label cible une version spécifique pour la mise à jour/suppression, tandis que la suppression sans version_label supprime toutes les versions.

Tableaux de bord

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
dashboard	x	x
dashboard_data		x

DevOps de base de données

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
database_schema	x	x	x	x	x
database_instance	x	x	x	x	x
database_snapshot_object	x	x
database_llm_authoring_pipeline		x

Gestion de l'infrastructure en tant que code (IaCM)

Les ressources IaCM sont activées par défaut et principalement limitées au projet. Commencez par iacm_workspace pour trouver les identifiants d'espace de travail, puis utilisez ce workspace_id pour les ressources d'espace de travail, les coûts et les différences d'activité. Utilisez iacm_variable_set pour les ensembles de variables réutilisables au niveau du compte, de l'organisation ou du projet. Le registre de fournisseurs est limité au compte.

iacm_module couvre les portées compte, organisation et projet. Il utilise par défaut le registre du compte ; chaque opération (lister, obtenir, créer, mettre à jour) envoie les mêmes paramètres de requête scope_org / scope_project, donc un module que vous créez est découvrable à la portée où vous l'avez créé. Sélectionnez la portée avec resource_scope="account" | "org" | "project" plus org_id/project_id. La portée est facultative : lorsque resource_scope est omis, org_id/project_id s'appliquent uniquement si vous les transmettez explicitement — les valeurs par défaut configurées HARNESS_ORG/HARNESS_PROJECT ne sont pas appliquées, donc une configuration de projet ambiante ne peut pas enregistrer silencieusement un module de compte sous un projet. Les champs org/project du corps d'un module localisent son connecteur Git et ne sont pas liés à cette portée de visibilité.

La création/mise à jour de iacm_workspace renvoie { policy_evaluation } uniquement — suivez avec harness_get pour récupérer l'espace de travail. La création/mise à jour de iacm_variable_set et iacm_module renvoie la ressource elle-même. La création de iacm_provider renvoie { id } uniquement — suivez avec harness_get ; la mise à jour est uniquement orientée version (POST/PUT /providers/{id}/version) — il n'y a pas de PUT de métadonnées. Les écritures de version peuvent renvoyer un corps vide ; HarnessClient normalise cela en { status: "SUCCESS", message: "No content" }.

La mise à jour d'un ensemble de variables est un PUT HTTP avec des collections de remplacement complet — toujours harness_get d'abord, puis PUT le corps complet souhaité (terraform_variables / environment_variables sont requis lors de la mise à jour ; omettre/vider efface les connecteurs et les fichiers de variables). La mise à jour de module est également un PUT — préférez obtenir-puis-PUT pour les champs facultatifs. Les écritures sont medium_write et nécessitent une confirmation (sollicitation ou confirm: true).

Le RBAC des ensembles de variables et du registre de fournisseurs (iac_variableset_*, iac_providerregistry_*) est actuellement expérimental dans Harness — les contrôles d'accès autorisent toujours jusqu'à ce que le serveur iac active l'application. Le RBAC du registre de modules (iac_registry_view / iac_registry_edit) est actif et applicable. MCP transmet toujours le PAT/SAT de l'appelant sans modification.

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
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

Flux de travail typique :

1. harness_list(resource_type="iacm_workspace", org_id="...", project_id="...") pour trouver l'espace de travail.
2. harness_create / harness_update sur iacm_workspace pour créer à partir de zéro ou d'un modèle (associated_template), ou mettre à jour un espace de travail existant — la réponse est { policy_evaluation } uniquement.
3. harness_get(resource_type="iacm_workspace", workspace_id="...") pour récupérer l'espace de travail créé/mis à jour.
4. harness_list / harness_create / harness_update sur iacm_variable_set (éventuellement avec resource_scope) pour les ensembles de variables Terraform/env réutilisables — la réponse est la ressource VariableSet.
5. harness_list / harness_create / harness_update sur iacm_module pour le registre de modules (name + system requis ; ajoutez resource_scope avec org_id/project_id pour un module limité à l'organisation ou au projet) — la réponse est la ressource module.
6. harness_list / harness_create / harness_update sur iacm_provider pour le registre de fournisseurs du compte (body.type requis pour la création ; la création renvoie { id } uniquement — puis harness_get ; la mise à jour crée/met à jour uniquement les versions) — la mise à jour de version peut renvoyer un succès vide.
7. harness_list(resource_type="iacm_resource", org_id="...", project_id="...", workspace_id="...") pour inspecter les ressources Terraform, les sorties et les sources de données.
8. harness_list(resource_type="iacm_workspace_costs", org_id="...", project_id="...", workspace_id="...") pour examiner les entrées de coûts par exécution.
9. harness_list(resource_type="iacm_activity_resource_change", org_id="...", project_id="...", activity_id="...", workspace_id="...") pour inspecter les différences de ressources avant/après pour une activité de plan, d'application ou de destruction.

Les réponses de liste IaCM exposent page_count comme le nombre pour la page actuelle uniquement (sauf iacm_variable_set, qui n'est pas paginé). Lorsque has_more est vrai, continuez à demander la page suivante basée sur 1 et additionnez les nombres de pages si vous avez besoin d'un total.

Portail développeur interne (IDP)

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
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

Demandes de tirage (Pull Requests)

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
pull_request	x	x	x	x		close, merge
pr_reviewer	x		x			submit_review
pr_comment			x	x	x	resolve, unresolve, set_status
pr_check	x
pr_activity	x

Utilisez harness_execute(resource_type="pull_request", action="close", ...) pour une opération de fermeture explicite. harness_update accepte également body.state (open ou closed) et achemine les changements d'état vers le point de terminaison d'état PR dédié de Harness Code ; envoyez les modifications de titre/description dans un appel de mise à jour séparé.

Utilisez harness_list(resource_type="pr_activity", filters={type: ["comment", "code-comment"]}, ...) pour lire les commentaires de PR. Utilisez pr_comment pour les opérations d'écriture de commentaires.

Utilisez harness_execute(resource_type="pr_comment", action="resolve", ...) pour résoudre un fil de commentaires et action="unresolve" pour le rouvrir ; aucun des deux ne prend de corps. Utilisez action="set_status" avec body={status: "resolved"} ou {status: "active"} pour définir l'état explicitement. comment_id doit être le id d'une ligne de pr_activity où le parent_id de cette ligne est null ; le backend rejette les identifiants de réponse.

Gestion des versions (Release Management)

Les ressources de gestion des versions (RMG) sont activées par défaut. Les ressources de définition (release_process, release_activity) prennent en charge lister/obtenir/créer/mettre à jour/supprimer avec body.yaml ; appelez harness_schema(resource_type="release_process"|"release_activity") avant la création/mise à jour. Les ressources d'exécution surveillent les versions en cours — la plupart des opérations de liste nécessitent release_id (UUID de harness_list resource_type=release, ou le slug d'URL d'interface tel que identifier-1.0.0-abc). Collez une URL de version RMG dans harness_list pour remplir automatiquement release_id.

Les appels RMG utilisent ${HARNESS_BASE_URL}/gateway/rmg avec un cadrage de compte via l'en-tête Harness-Account. Le cadrage Org/projet utilise un cadrage basé sur les en-têtes lorsque org_id/project_id sont fournis. release_execution_phase est en lecture seule — utilisez le champ identifier de chaque élément de phase comme params.phase_identifier lors de l'appel de harness_get sur les ressources d'entrée/sortie de phase (n'appelez pas harness_get sur release_execution_phase lui-même). Le filtrage status de la liste des versions est appliqué côté client sur la page courante uniquement ; conservez la pagination avec les mêmes filtres lorsque les résultats peuvent s'étendre sur plusieurs pages.

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
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

Flux de travail typique :

1. harness_list(resource_type="release_process", org_id="...", project_id="...") pour découvrir les définitions de processus d'orchestration.
2. harness_schema(resource_type="release_process") (ou release_activity) avant la création/mise à jour ; puis harness_create / harness_update avec body.yaml.
3. harness_list(resource_type="release", org_id="...", project_id="...") pour trouver les versions actives ou récentes (fenêtre de rétrospection de 30 jours par défaut ; filters.status, filters.search_term, filters.days_back en option).
4. harness_get(resource_type="release", release_id="...") pour les détails de la version.
5. harness_list(resource_type="release_execution_phase", filters={ release_id: "..." }) pour le statut de la phase ; même release_id pour release_execution_task et release_execution_activity.
6. harness_get sur release_input, release_execution_phase_input, release_execution_phase_output, release_execution_activity_output ou release_execution_activity_input en utilisant release_id plus params.phase_identifier / params.activity_identifier / activity_execution_id comme documenté sur chaque ressource.

Vibe

L'ensemble d'outils vibe activé par défaut couvre le contrat BFF Vibe Orchestrator sous ${HARNESS_BASE_URL}/vibe/v1. Il utilise la connexion Harness existante et l'en-tête de compte, sans ajouter de paramètres de requête account/org/project ni de champs de portée aux corps de requête. L'équipe a validé le flux Vibe en utilisant l'authentification par clé API Harness (PAT/SAT), donc aucun paramètre d'activation n'est requis pour les sessions par défaut. Les documents OpenAPI organisés décrivent l'authentification par jeton bearer/session ; le mode OAuth du serveur transmet le jeton bearer de la session en cours. Les régressions automatisées vérifient les deux chemins d'en-tête ; l'authentification par passerelle reste soumise à la configuration de l'environnement cible.

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
vibe_project			x			prepare, deploy
vibe_app_lifecycle		x				events

L'API prend en charge deux chemins d'admission. Conservez ces formes de requête natives de l'API :

Source disponible pour l'agent de codage	Flux API
Lien/connecteur de dépôt GitHub	harness_create avec resource_type="vibe_project" et body.mode plus les champs spécifiques au mode. Le contrat nomme github_link et github_connector mais ne définit pas leurs formes de champs URL, branche ou connecteur ; ces champs sont transmis au backend sans inventer de correspondance.
Fichier ZIP	Appelez prepare avec le nom de l'application et les métadonnées du fichier, téléversez les octets vers la cible signée retournée, puis appelez deploy.
Répertoire source local	L'agent de codage archive la source du workspace prévu dans un ZIP localement, puis suit le flux ZIP. Un chemin local ou un contexte conversationnel n'est pas un téléversement de source pris en charge par l'API.

Lors de l'empaquetage d'un répertoire, incluez la source, les manifestes, les lockfiles, la configuration et les modifications non validées prévues nécessaires à sa construction. Excluez les identifiants, .git, les dépendances installées et les artefacts générés. L'empaquetage et le téléversement signé se produisent là où les fichiers sont accessibles ; un serveur MCP hébergé ne peut pas lire le répertoire local de l'agent de codage.

Pour un ZIP existant, préparez le téléversement :

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

Passez ceci à harness_execute. La taille doit décrire le ZIP réel ; size_bytes, content_type et md5 sont facultatifs et nullables. Les champs de préparation supplémentaires sont conservés pour la validation du backend, comme le permet l'OpenAPI. La préparation retourne projectId, sourceId et upload, y compris le uploadUrl, method, headers et expiresAt de chaque fichier. Téléversez les octets du fichier directement en utilisant cette URL signée, cette méthode et ces en-têtes ; préservez l'URL exactement et n'ajoutez pas d'identifiants Harness à la requête de stockage. L'action de préparation ne lit ni ne téléverse les fichiers locaux.

Après un téléversement réussi, déployez explicitement :

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

Pour les importations JSON, utilisez le id retourné à la place. Le déploiement accepte également body: {"project_id": "<Vibe app id>"} ou params.app_id ; le champ filaire de l'API est en snake_case project_id même si la préparation retourne du camelCase projectId. Le project_id de niveau supérieur de l'outil générique est un identifiant de portée Harness et n'est jamais utilisé comme identifiant d'application Vibe. L'importation et la préparation créent l'application/source ; aucune ne démarre le déploiement. Les écritures ne sont pas automatiquement réessayées, et le déploiement utilise la politique de confirmation à haut risque existante.

Lisez la progression avec harness_get(resource_type="vibe_app_lifecycle", resource_id="<Vibe app id>"). Il conserve les URL d'application, les étapes d'exécution, les sous-étapes, les échecs, les lignes de journal et les détails de l'analyseur de build. L'action d'exécution events accepte resource_id ou params.app_id et consomme le point de terminaison SSE comme un lot fini : jusqu'à 20 événements JSON ou cinq secondes après la connexion, avec une limite de réponse de 1 Mio. Ces limites appartiennent au point de terminaison Vibe. Le HARNESS_API_TIMEOUT_MS de la connexion borne également la consommation de la connexion et du flux ensemble ; l'expiration retourne une erreur de délai. Un lot terminé retourne events et stop_reason (end, event_limit ou duration_limit) et ferme le flux. Ni les échecs de connexion initiaux ni les flux interrompus ne sont réessayés. Les événements sont des diffs transitoires sans curseur de relecture documenté ; utilisez l'obtention du cycle de vie pour un instantané faisant autorité. Les deux lectures du cycle de vie sont disponibles en mode lecture seule.

Feature Flags

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
fme_workspace	x
fme_environment	x	x	x	x	x
fme_feature_flag	x	x	x	x	x	kill, restore, reallocate, archive, unarchive
fme_feature_flag_definition	x	x	x	x	x	kill, restore, reallocate
fme_rollout_status	x
fme_rule_based_segment	x	x	x		x
fme_rule_based_segment_definition	x			x		enable, disable, change_request
fme_traffic_type	x
fme_identity			x	x
fme_standard_segment	x	x
fme_segment_keys	x			x
fme_segment	x	x	x	x	x
fme_segment_definition	x	x	x	x	x	list_keys, add_keys, remove_keys
fme_metric	x	x	x	x	x
fme_event_type	x	x
fme_experiment	x	x	x	x	x
fme_experiment_settings		x		x	x
fme_experiment_result	x

Ressources FME (Split.io) — les ressources fme_* prennent en charge le cadrage à double mode : les appels hérités passent workspace_id et atteignent l'API Split.io (api.split.io) ; les appels plus récents passent org_id+project_id ensemble et atteignent les points de terminaison natifs Harness (HARNESS_API_KEY/HARNESS_BASE_URL standard, même authentification que toute autre ressource harness_*) à la place. Passer à la fois workspace_id et org_id/project_id sur le même appel, ou mélanger org_id avec project_id seul, est une erreur — choisissez un mode par appel. Chaque opération ci-dessous est disponible en mode hérité, inchangée, sauf si la ressource est marquée comme native Harness uniquement. La couverture du mode natif Harness est actuellement plus restreinte :

• fme_workspace — pas d'équivalent natif Harness ; hérité uniquement (utilisé pour découvrir les valeurs workspace_id).

• fme_environment — list à double mode (workspace_id ou org_id+project_id). get/create/update/delete sont natifs Harness uniquement (/fme/api/v4/environments) — MCP n'a jamais eu de contrat workspace_id pour ces opérations. La liste native utilise offset/limit optionnels (max 100 ; harness_list size mappe vers limit) ; l'enveloppe {data, limit, offset, totalCount} est promue en items/total. La création/mise à jour native utilise isProduction (production accepté comme alias). La mise à jour native est un JSON Merge Patch ; name et isProduction ne sont pas effaçables. Nom max 15 caractères.

• fme_feature_flag — double mode, les deux branches entièrement câblées. Natif Harness (org_id+project_id) : list/get/create/delete atteignent /fme/api/v4/feature-flags (corps pour create : name, trafficType, description/tags/owners optionnels, par CreateFeatureFlagRequest) ; update envoie un merge-patch à /fme/api/v4/feature-flags/{name} ; archive/unarchive atteignent /fme/api/v4/feature-flags/{name}/archive|unarchive (comment optionnel uniquement — pas de title, par ArchiveUnarchiveRequest) ; kill/restore/reallocate atteignent /fme/api/v4/feature-flag-definitions/{name}/kill|restore|reallocate avec environment_id comme paramètre de requête (comment/title optionnels, par FeatureFlagDefinitionActionRequest).

• fme_feature_flag_definition — get/create/update restent en double mode (workspace_id ou org_id+project_id). list/delete/kill/restore/reallocate sont natifs Harness uniquement (org_id+project_id) — MCP n'a jamais eu de contrat workspace_id pour ces opérations. La liste native exige feature_flag_name et utilise offset/limit (défaut 100, max 100) ; elle ne prend pas environment_id. Suppression et exécution exigent environment_id. Kill/restore/reallocate sont les mêmes actions que sur fme_feature_flag. Le corps get/create/update correspond à l'héritage (treatments, defaultTreatment, defaultRule, rules/baselineTreatment/trafficAllocation/comment optionnels), plus title optionnel en mode natif Harness. La mise à jour native est un JSON Merge Patch.

• fme_rollout_status — list à double mode. Passez org_id+project_id (préféré) ou le workspace_id obsolète. La pagination native utilise offset/limit (max 100 ; harness_list size mappe vers limit) ; les résultats sont promus en items/total. Chaque élément a id, name, et description optionnel.

• fme_rule_based_segment — (Obsolète — voir fme_segment.) Le mode natif Harness est rejeté sur chaque opération (list/get/create/delete) — utilisez fme_segment à la place ; cette ressource ne prend en charge que le contrat hérité workspace_id.

• fme_rule_based_segment_definition — (Obsolète — voir fme_segment_definition.) Le mode natif Harness est rejeté sur chaque opération/action (list/update/enable/disable/change_request) — utilisez fme_segment_definition à la place (pas d'équivalent enable/disable/change_request là-bas) ; cette ressource ne prend en charge que le contrat hérité workspace_id/environment_id.

• fme_traffic_type — list à double mode. Passez org_id+project_id (préféré) ou le workspace_id obsolète. La pagination native utilise offset/limit (max 100 ; harness_list size mappe vers limit) ; les résultats sont promus en items/total. Chaque élément a id et name (pas de displayAttributeId).

• fme_identity — create/update ne sont pas encore implémentés si org_id+project_id sont passés ensemble ; sinon, procède comme un appel hérité normal.

• fme_standard_segment — obsolète. Le workspace_id hérité atteint toujours Split v2. Le natif Harness est rejeté — utilisez fme_segment.

• fme_segment_keys — list/update restent hérités (workspace_id / environment_id+segment_name). Le natif Harness (org_id+project_id) est rejeté — utilisez fme_segment_definition exécutez list_keys/add_keys/remove_keys.

• fme_segment — Natif uniquement (org_id+project_id). CRUD. list/get/update/delete exigent segment_type : STANDARD | LARGE | RULE_BASED. Corps de création : name, trafficType, segmentType ; description, tags, owners optionnels.

• fme_segment_definition — Natif uniquement. CRUD plus exécution list_keys/add_keys/remove_keys. La mise à jour est description uniquement. La suppression échoue avec hasDependents tant que des clés restent.

• fme_metric — Natif Harness uniquement (pas de support hérité workspace_id). list/get/create/update/delete sont câblés à /fme/api/v4/metrics (le harness_list size de list mappe vers limit). create exige spread même si le backend CreateMetricRequest le garde optionnel (défaut PER) — un contrat plus strict côté MCP uniquement, car l'omettre change silencieusement la sémantique d'une métrique RATE. update est un JSON Merge Patch ; name/trafficType sont immuables et non acceptés. delete est une suppression définitive (pas d'archive/restauration) — classé destructive.

• fme_event_type — Natif Harness uniquement (pas de support hérité workspace_id). Lecture seule : list/get sont câblés à /fme/api/v4/event-types ; id est le nom de l'événement. Seuls les types d'événements avec des événements dans les 30 derniers jours sont visibles ; get renvoie un 404 pour un type d'événement hors du périmètre de type de trafic de l'espace de travail demandeur, ou inactif depuis plus de 30 jours. Filtres de liste : name (sous-chaîne), traffic_type (par ID ou nom), offset/limit (harness_list size mappe vers limit). Utilisez ceci pour découvrir les vrais IDs de types d'événements avant d'en référencer un dans le baseEventTypes/filterEventType ou le filtre event_type_ids de fme_metric, au lieu de deviner un ID.

• fme_experiment — Natif Harness uniquement (pas de support hérité workspace_id). CRUD câblé à /fme/api/v4/experiments. list exige parent_type (FEATURE_FLAG, AI_CONFIG ; CONFIG renvoie 404) et par défaut à ACTIVE expériences sauf si status est passé. create exige environment_id (paramètre de requête) plus parent/name/startAt/endAt/baselineTreatment/comparisonTreatments dans le corps ; le parent doit exister dans cet environnement. update est un JSON Merge Patch ; parent et environment ne peuvent pas être modifiés. delete est une suppression définitive — classé destructive. owners optionnel sur création/mise à jour : chaque entrée est {type: "USER", id or email} ou {type: "GROUP", identifier}.

• fme_experiment_settings — Paramètres statistiques et de surveillance pour une seule expérience (type de test, seuil de significativité, correction de comparaisons multiples, taille d'échantillon minimale, période de revue, réduction de variance). get/update/delete uniquement — 1:1 avec l'expérience, pas de list. get renvoie toujours les paramètres appliqués (propre remplacement ou défauts d'organisation) et ne renvoie jamais 404 sauf si l'expérience elle-même n'existe pas. update est un JSON Merge Patch et crée implicitement le remplacement au niveau de l'expérience. delete revient aux défauts d'organisation (idempotent) — classé destructive même si c'est non permanent.

• fme_experiment_result — Résultats évalués par métrique pour le dernier cycle de calcul d'une expérience. list uniquement (pas de get — les résultats n'ont pas d'identifiant propre). Une ligne par paire (métrique, traitement de comparaison) dans toutes les catégories de métriques. Filtres optionnels : metric_ids, comparisons. Reflète uniquement le dernier cycle — pas d'accès historique.

En mode mono-utilisateur/auto-hébergé, l'authentification en mode hérité utilise un jeton Bearer de HARNESS_FME_API_KEY, avec repli sur un HARNESS_API_KEY non-placeholder. HARNESS_FME_API_KEY peut être une clé admin Split héritée ou un PAT/SAT Harness avec droit FME, mais il est rejeté en mode multi-user afin que les déploiements partagés ne puissent pas écraser les identifiants de chaque utilisateur de session. Les identifiants OAuth/routage de service hébergés pour les API de plateforme Harness n'authentifient pas les requêtes Split.io directes. fme_feature_flag prend en charge la gestion complète du cycle de vie en mode hérité : créer (exige traffic_type_id), lister, obtenir, mettre à jour les métadonnées, supprimer, et exécuter les actions kill/restore/reallocate/archive/unarchive. Utilisez fme_traffic_type pour découvrir les IDs de types de trafic, fme_identity pour créer/mettre à jour les attributs d'identité, et fme_standard_segment / fme_segment_keys pour inspecter les segments standard et ajouter des clés membres. fme_rule_based_segment fournit le CRUD pour les segments de ciblage, tandis que fme_rule_based_segment_definition gère les règles de segments spécifiques à l'environnement avec flux d'activation/désactivation et d'approbation de demandes de modification.

GitOps

Type de ressource	Liste	Obtenir	Créer	Mettre à jour	Supprimer	Actions d'exécution
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

Ingénierie du chaos

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
chaos_experiment	x	x	x		x	run, stop
chaos_experiment_run		x
chaos_experiment_variable	x
chaos_component_variable		x
chaos_input_set	x	x	x	x	x
chaos_experiment_template	x	x			x	create_from_template, list_revisions, get_variables, get_yaml, compare_revisions
chaos_probe	x	x	x		x	enable, verify, get_manifest
chaos_probe_in_run	x
chaos_probe_template	x	x			x	get_variables
chaos_infrastructure	x
chaos_k8s_infrastructure	x	x	x			check_health
chaos_enabled_infrastructure	x
chaos_environment	x
chaos_hub	x	x	x	x	x
chaos_hub_fault	x
chaos_fault	x	x			x	get_variables, get_yaml
chaos_fault_template	x	x			x	list_revisions, get_variables, get_yaml, compare_revisions
chaos_fault_experiment_run	x
chaos_action	x	x	x		x	get_manifest
chaos_action_template	x	x			x	list_revisions, get_variables, compare_revisions
chaos_loadtest	x	x	x	x	x	run, stop
chaos_service	x	x	x	x	x	list_experiment_runs, list_load_tests
chaos_application_map	x	x
discovered_agent	x
discovered_namespace	x
discovered_service	x
discovered_network_map	x
chaos_guard_condition	x	x			x
chaos_guard_rule	x	x			x	enable
chaos_recommendation	x	x
chaos_risk	x	x
chaos_dr_test	x		x
scanned_risk	x	x				occurrences, summary_by_service
chaos_risk_rule	x	x
chaos_risk_scan	x	x	x	x	x	retry, abort, report, report_download, heatmap

Gestion des coûts cloud (CCM)

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
cost_perspective	x	x	x	x	x
cost_breakdown	x
cost_timeseries	x
cost_summary	x	x
cost_recommendation	x	x				update_state, override_savings, create_jira_ticket, create_snow_ticket
cost_anomaly	x
cost_anomaly_summary		x
cost_category	x	x
cost_account_overview		x
cost_filter_value	x
cost_recommendation_stats		x
cost_recommendation_detail		x
cost_commitment		x
ai_budget	x	x	x	x	x
ai_budget_overview		x
ai_budget_consumption	x
ai_budget_override_request	x	x	x			approve, reject

Informations sur l'ingénierie logicielle (SEI)

Les ressources SEI sont consolidées pour l'efficacité des jetons. Utilisez les paramètres metric ou aspect pour DORA, les détails de l'équipe/arborescence organisationnelle et les informations IA.

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
sei_metric	x
sei_productivity_metric		x
sei_dora_metric		x				Passez metric : deployment_frequency, change_failure_rate, mttr, lead_time, ou *_drilldown
sei_team	x	x
sei_team_detail	x					Passez aspect : integrations, developers, integration_filters
sei_org_tree	x	x
sei_org_tree_detail	x	x				Passez aspect : efficiency_profile, productivity_profile, business_alignment_profile, integrations, teams
sei_business_alignment	x	x				Passez aspect : feature_metrics, feature_summary, drilldown pour obtenir
sei_ai_usage	x	x				Passez aspect : metrics, breakdown, summary, top_languages
sei_ai_adoption	x	x				Passez aspect : metrics, breakdown, summary
sei_ai_impact		x				Passez aspect : pr_velocity, rework
sei_ai_raw_metric	x

Assurance de la chaîne d'approvisionnement logicielle (SCS)

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
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

Coffre de preuves

Le coffre de preuves stocke les attestations in-toto (preuves SDLC). La liste prend en charge la portée compte/org/projet via resource_scope. Les filtres de texte libre singuliers (pipeline, artefact seul, gitoid) utilisent search_term ; une contrainte de nom supplémentaire utilise filters.subject_name ; le condensé du contenu du sujet utilise filters.subject_digest. Obtenir effectue une recherche par gitoid_sha256 et nécessite org_id/project_id (à partir de la ligne de la liste). Télécharger (action harness_execute download) renvoie un download_url limité dans le temps — affichez toujours ce lien à l'utilisateur. Nécessite le drapeau de fonctionnalité SCS_EVIDENCE_VAULT.

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
attestation	x	x				download

Orchestration des tests de sécurité (STO)

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
security_issue	x
security_issue_filter	x
security_exemption	x		x			approve, reject
remediation_diff	x

La création de security_exemption est une opération high_write. Le serveur dérive requester_id du PAT authentifié, définit exemptFutureOccurrences=true, et par défaut duration_days à 30 lorsqu'il n'est pas fourni. Pour lister les exemptions, passez une taille de page explicite et petite (par exemple filters: { "status": "Pending", "size": 5 }) et suivez le _nextPageHint renvoyé dans chaque réponse.

Flux de travail d'exécution des exemptions de sécurité :

• Utilisez harness_list avec resource_type="security_exemption" et un status explicite tel que Pending, Approved, Rejected, Expired, ou Canceled.
• Utilisez harness_execute avec action="approve" et un body.scope requis : CURRENT, ACCOUNT, ORG, ou PROJECT. CURRENT approuve à la portée existante de l'exemption ; les autres portées utilisent le point de terminaison de promotion STO en interne. Le serveur remplit automatiquement body.approver_id à partir de l'utilisateur authentifié lorsqu'il est omis ; body.comment est facultatif.
• Utilisez action="reject" pour rejeter une exemption. body.approver_id est également rempli automatiquement lorsqu'il est omis.
• Il n'existe pas d'action d'exécution promote distincte. Utilisez action="approve" avec un body.scope non-CURRENT lorsque le résultat demandé est une approbation à la portée compte, organisation ou projet.

Contrôle d'accès

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
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

Gouvernance

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
policy	x	x	x	x	x
policy_set	x	x	x	x	x
policy_evaluation	x	x

Gel de déploiement

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
freeze_window	x	x	x	x	x	toggle_status
global_freeze		x				manage

Remplacements de service

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
service_override	x	x	x	x	x

Paramètres

Type de ressource	Lister	Obtenir	Créer	Mettre à jour	Supprimer	Exécuter des actions
setting	x

Invites MCP

DevOps

Prompt	Description	Paramètres
build-deploy-app	Workflow CI/CD de bout en bout : analyser un dépôt git, générer un pipeline CI (build et push d'image Docker), découvrir ou générer des manifests K8s, créer un pipeline CD, et déployer — avec nouvelle tentative automatique en cas d'échec CI (jusqu'à 5 tentatives) et d'échec CD (jusqu'à 3 tentatives avec permission de l'utilisateur). En cas d'épuisement des tentatives, fournit des liens profonds vers l'interface Harness pour toutes les ressources créées afin d'investigation manuelle.	repoUrl (obligatoire), imageName (obligatoire), projectId (facultatif), namespace (facultatif)
debug-pipeline-failure	Analyser une exécution en échec : accepte un ID d'exécution, un ID de pipeline ou une URL Harness. Obtient la répartition par étape, les détails de l'échec, les informations sur le délégué et les journaux de l'étape en échec via harness_diagnose, puis fournit une analyse de cause racine et des correctifs suggérés. Suit automatiquement les échecs de pipeline en chaîne.	executionId (facultatif), projectId (facultatif)
pipeline_summarizer	Récupérer et résumer TOUS les journaux d'étapes d'une exécution de pipeline. Utilise harness_diagnose avec include_logs: true, include_all_step_logs: true pour obtenir le journal de chaque étape, puis présente un tableau avec Nom de l'étape, Statut, Durée et Ce qui s'est passé (résumé basé sur les journaux). Ne saute AUCUNE étape.	executionId (facultatif), projectId (facultatif)
create-pipeline	Générer un nouveau YAML de pipeline à partir d'exigences en langage naturel, en examinant les ressources existantes pour le contexte	description (obligatoire), projectId (facultatif)
create-agent	Construire interactivement un agent IA Harness — vérifier les agents existants (détecter le format de spécification agent.uses actuel vs. agent.step.group.steps hérité lors de la mise à jour), recueillir les exigences, générer la spécification de l'agent au format approprié, confirmer avec l'utilisateur, puis créer ou mettre à jour via harness_create/harness_update	agent_name (obligatoire), task_description (obligatoire), org_id (facultatif), project_id (facultatif)
onboard-service	Parcourir l'intégration d'un nouveau service avec des environnements et un pipeline de déploiement	serviceName (obligatoire), projectId (facultatif)
dora-metrics-review	Examiner les métriques DORA (fréquence de déploiement, taux d'échec de changement, MTTR, délai d'exécution) avec classification Elite/Haut/Moyen/Bas et recommandations d'amélioration	teamRefId (facultatif), dateStart (facultatif), dateEnd (facultatif)
setup-gitops-application	Guider l'intégration d'une application GitOps — vérifier l'agent, le cluster, le dépôt, et créer l'application	agentId (obligatoire), projectId (facultatif)
chaos-resilience-test	Concevoir une expérience de chaos pour tester la résilience du service avec injection de fautes, sondes et résultats attendus	serviceName (obligatoire), projectId (facultatif)
feature-flag-rollout	Planifier et exécuter un déploiement progressif de drapeau de fonctionnalité à travers les environnements avec des barrières de sécurité	flagIdentifier (obligatoire), projectId (facultatif)
migrate-pipeline-to-template	Analyser un pipeline existant et en extraire des modèles d'étapes réutilisables	pipelineId (obligatoire), projectId (facultatif)
delegate-health-check	Vérifier la connectivité du délégué, la santé, le statut du jeton, et résoudre les problèmes d'infrastructure	projectId (facultatif)
developer-portal-scorecard	Examiner les scorecards IDP pour les services et identifier les lacunes pour améliorer l'expérience développeur	projectId (facultatif)
pending-approvals	Trouver les exécutions de pipeline en attente d'approbation, afficher les détails, et proposer d'approuver ou de rejeter	projectId (facultatif), orgId (facultatif), pipelineId (facultatif)

FinOps

Prompt	Description	Paramètres
optimize-costs	Analyser les données de coûts cloud, mettre en évidence les recommandations et anomalies, priorisées par économies potentielles	projectId (facultatif)
cloud-cost-breakdown	Analyse approfondie des coûts cloud par service, environnement ou cluster avec analyse des tendances et détection d'anomalies	perspectiveId (facultatif), projectId (facultatif)
commitment-utilization-review	Analyser l'utilisation des instances réservées et des plans d'économies pour trouver le gaspillage et optimiser les engagements	projectId (facultatif)
cost-anomaly-investigation	Enquêter sur les anomalies de coûts — déterminer la cause racine, les ressources impactées et la remédiation	projectId (facultatif)
rightsizing-recommendations	Examiner et prioriser les recommandations de redimensionnement, créer facultativement des tickets Jira ou ServiceNow	projectId (facultatif), minSavings (facultatif)

DevSecOps

Prompt	Description	Paramètres
security-review	Examiner les problèmes de sécurité à travers les ressources Harness et suggérer des remédiations par gravité	projectId (facultatif), severity (facultatif, défaut : critical,high)
vulnerability-triage	Trier les vulnérabilités de sécurité à travers les pipelines et artefacts, prioriser par gravité et exploitabilité	projectId (facultatif), severity (facultatif)
sbom-compliance-check	Auditer la SBOM et la posture de conformité des artefacts — risques de licence, violations de politique, vulnérabilités de composants	artifactId (facultatif), projectId (facultatif)
supply-chain-audit	Audit de sécurité de la chaîne d'approvisionnement logicielle de bout en bout — provenance, chaîne de garde, conformité politique	projectId (facultatif)
security-exemption-review	Examiner les exemptions de sécurité en attente et prendre des décisions d'approbation ou de rejet par lot	projectId (facultatif)
bulk-exemption-create	Créer des exemptions de sécurité justifiées pour plusieurs problèmes STO avec portée explicite et conseils de durée	projectId (obligatoire), exemption_type (obligatoire), reason (obligatoire), filtres de problèmes (facultatif)
access-control-audit	Auditer les permissions utilisateur, les comptes sur-privilégiés et les attributions de rôles pour appliquer le moindre privilège	projectId (facultatif), orgId (facultatif)

Harness Code

Prompt	Description	Paramètres
code-review	Examiner une demande de tirage (pull request) — analyser le diff, les commits, les vérifications et les commentaires pour fournir un retour structuré sur les bogues, la sécurité, les performances et le style	repoId (requis), prNumber (requis), projectId (facultatif)
pr-summary	Générer automatiquement un titre et une description de PR à partir de l'historique des commits et du diff d'une branche	repoId (requis), sourceBranch (requis), targetBranch (facultatif, défaut : main), projectId (facultatif)
branch-cleanup	Analyser les branches d'un dépôt et recommander les branches obsolètes ou fusionnées à supprimer	repoId (requis), projectId (facultatif)

Ressources MCP

URI de ressource	Description	Type MIME
pipeline:///{pipelineId}	Définition YAML de pipeline	application/x-yaml
pipeline:///{orgId}/{projectId}/{pipelineId}	YAML de pipeline (avec portée explicite)	application/x-yaml
executions:///recent	Résumés des 10 dernières exécutions de pipeline	application/json
schema:///pipeline	Schéma JSON du pipeline Harness	application/schema+json
schema:///template	Schéma JSON du modèle Harness	application/schema+json
schema:///trigger	Schéma JSON du déclencheur Harness	application/schema+json
schema:///pipeline_v1 (Alpha)	Schéma JSON du pipeline Harness V1 (format simplifié des étapes/stages)	application/schema+json
schema:///agent-pipeline	Schéma JSON du pipeline de l'agent IA Harness	application/schema+json
agent-docs:///legacy-format	Référence du format de spécification d'agent hérité (agent.step.group.steps / PLUGIN_TASK), lue par le prompt create-agent lors de la mise à jour d'un agent au format hérité	text/markdown

Filtrage des ensembles d'outils

Par défaut, 42 des 46 ensembles d'outils sont activés. Quatre ensembles d'outils sont facultatifs et exclus des valeurs par défaut :

• ansible — Harness Ansible (inventaires, playbooks, hôtes, activité). Facultatif car il est limité au projet et ajoute des concepts dont de nombreux utilisateurs n'ont pas besoin.
• autonomous_work — Harness de développement (travail autonome). Facultatif ; voir la description de l'ensemble d'outils pour la portée.
• observability-evaluations — Règles d'évaluation de télémétrie de production planifiées. Facultatif car il dépend du plan de contrôle de notation déployé.
• registries-v3 — Registre d'artefacts Harness v3 (paquets, versions, fichiers, métadonnées, analyses, exceptions de pare-feu). Facultatif jusqu'à ce que les écritures v3 soient disponibles, afin que les agents n'aient pas à faire la distinction entre les registres/artefacts v1 et les paquets/versions v3.

Ajout d'ensembles d'outils avec le préfixe +

Utilisez le préfixe + pour inclure explicitement les ensembles d'outils facultatifs en plus de toutes les valeurs par défaut :

# Explicitly include Ansible alongside all defaults
HARNESS_TOOLSETS=+ansible

Suppression des ensembles d'outils par défaut

Utilisez le préfixe - pour exclure les ensembles d'outils dont vous n'avez pas besoin :

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

Combinaison de + et -

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

Liste d'autorisation explicite

Une liste explicite séparée par des virgules (sans préfixes) remplace entièrement les valeurs par défaut. Seuls les ensembles d'outils répertoriés sont activés :

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

Noms des ensembles d'outils disponibles :

Toolset	Types de ressources
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, fme_experiment, fme_experiment_settings, fme_experiment_result
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
timelines	activity_timeline

Architecture

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

Comment ça fonctionne

1. Les outils sont des verbes génériques : harness_list, harness_get, etc. Ils acceptent un paramètre resource_type qui achemine vers le point de terminaison API approprié.
2. Le registre associe chaque resource_type à un ResourceDefinition — une structure de données déclarative spécifiant la méthode HTTP, le chemin d'URL, les correspondances de paramètres de chemin/requête et la logique d'extraction des réponses.
3. La répartition résout la définition de ressource, construit la requête HTTP (substitution de chemin, paramètres de requête, injection de compte/org/projet compatible resource_scope), appelle l'API Harness via HarnessClient et extrait les données de réponse pertinentes.
4. Le filtrage des ensembles d'outils (HARNESS_TOOLSETS) contrôle quelles définitions de ressources sont chargées dans le registre au démarrage.
5. La sortie structurée est déclarée avec les outputSchema MCP ; harness_list convertit les tableaux et les wrappers de listes courants en structuredContent en forme d'objet pour les clients stricts.
6. Les liens profonds sont automatiquement ajoutés aux réponses, fournissant des URL directes de l'interface Harness pour chaque ressource.
7. Le mode compact supprime les métadonnées verbeuses des résultats de liste, ne conservant que les champs exploitables (identité, statut, type, horodatages, liens profonds) pour minimiser l'utilisation de jetons.

Ajout d'un nouveau type de ressource

Créez un nouveau fichier dans src/registry/toolsets/ ou ajoutez une ressource à un ensemble d'outils existant :

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

Ensuite, importez-le dans src/registry/index.ts et ajoutez-le au tableau ALL_TOOLSETS. Aucune modification n'est nécessaire dans les fichiers d'outils.

Développement

# 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

Structure du projet

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

Élicitation

Les outils d'écriture (harness_create, harness_update, harness_delete, harness_execute) utilisent l'élicitation MCP pour demander une confirmation à l'utilisateur lorsque le risque de l'action l'exige — opérations medium_write, high_write et destructive uniquement. Les créations/mises à jour/lectures à faible risque (par exemple pipeline.create, pipeline.update, hql_query.run) se déroulent silencieusement sans invite. Lorsqu'une invite est affichée, l'utilisateur voit ce qui va se passer et accepte ou refuse, offrant une véritable approbation humaine dans la boucle pour les opérations qui modifient ou exécutent réellement des choses.

Comment cela fonctionne :

1. Le LLM appelle un outil d'écriture avec un risque medium_write+ (par exemple harness_delete, harness_execute pipeline.run). Les créations/mises à jour/lectures à faible risque n'affichent pas d'invite.
2. Le serveur envoie une demande d'élicitation au client avec un résumé de l'opération et une case à cocher confirm (cochée par défaut).
3. L'utilisateur voit les détails et clique sur Accepter (avec confirm coché) ou Refuser / Annuler.
4. Si accepté avec confirm: true, l'opération se poursuit. Si accepté avec confirm décoché, refusé ou annulé, elle est bloquée et le LLM en est informé (un refus explicite est autoritatif et n'est pas contourné par confirm: true sur l'appel d'outil).

Prise en charge client :

Client	Prise en charge de l'élicitation
Cursor	Oui
VS Code (Copilot)	Oui
Claude Desktop	Pas encore
Devin Desktop	Pas encore
MCP Inspector	Oui

Le comportement d'élicitation varie selon le risque de l'opération lorsque la prise en charge client est absente :

Niveau de risque	Le client prend en charge l'élicitation	confirm: true transmis	Comportement
read, low_write	quelconque	quelconque	Procéder silencieusement — aucune invite n'est affichée (confirm n'a aucun effet à ce niveau de risque)
medium_write, high_write, destructive	Oui	quelconque	Inviter l'utilisateur. Procéder uniquement si l'utilisateur accepte avec confirm: true (la valeur par défaut du schéma). Un refus explicite, une annulation ou une acceptation avec confirm: false (case décochée par l'utilisateur) est autoritatif et n'est pas contourné par confirm: true sur l'appel d'outil. Une acceptation sans le champ confirm est traitée comme un échec du client à afficher une invite utilisable — récupérable en réessayant avec confirm: true
medium_write, high_write, destructive	Non	Non	BLOQUER (renvoyer une erreur avec un conseil de réessayer avec confirm: true)
medium_write, high_write, destructive	Non	Oui	Procéder (adhésion explicite pour l'automatisation non interactive)
quelconque (au niveau ou en dessous de HARNESS_AUTO_APPROVE_RISK)	quelconque	quelconque	Approbation automatique sans invite

Si elicitInput échoue au moment de l'exécution (erreur de transport, méthode non prise en charge) pour une opération medium_write+, l'appel est bloqué à moins que l'appelant ne transmette confirm: true. confirm: true est honoré comme solution de repli lorsque le client n'a pas pu afficher d'invite ou a renvoyé une acceptation dégénérée ({action: "accept"} sans le champ de confirmation), mais il ne remplace pas un refus/annulation explicite d'un client ayant complété la poignée de main d'élicitation.

Mode autonome

Le mode autonome signifie que le serveur procède à toutes les opérations — y compris les écritures et les actions destructrices — sans demander de confirmation. Activez-le en définissant :

HARNESS_AUTO_APPROVE_RISK=all

C'est le plafond au niveau du déploiement : une fois défini, les sessions individuelles ne peuvent pas dépasser ce niveau (bien qu'elles puissent choisir un seuil plus strict par session via l'en-tête x-harness-auto-approve-risk).

Ou dans la configuration de votre client MCP :

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

Autonomie partielle : Vous pouvez également approuver automatiquement uniquement jusqu'à un niveau de risque spécifique tout en demandant une invite pour les opérations à risque plus élevé :

# 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

Valeur	Ce qui est approuvé automatiquement
none (défaut)	Rien — aucun seuil d'approbation automatique
low_write	Lectures + écritures à faible risque
medium_write	Lectures + écritures à faible et moyen risque
high_write	Lectures + écritures à faible, moyen et haut risque
all	Tout, y compris les opérations destructrices

Avertissement sur le mode autonome : HARNESS_AUTO_APPROVE_RISK=all ignore la confirmation pour toutes les opérations, y compris harness_delete. Utilisez avec prudence et envisagez de l'associer à HARNESS_TOOLSETS pour restreindre les types de ressources disponibles.

Note de migration : HARNESS_SKIP_ELICITATION=true est toujours pris en charge et correspond à HARNESS_AUTO_APPROVE_RISK=all. Un avertissement de dépréciation est journalisé sur stderr. Si les deux sont définis, HARNESS_AUTO_APPROVE_RISK a priorité.

Sécurité

• Les secrets ne sont jamais exposés. Le type de ressource secret ne renvoie que des métadonnées (nom, type, portée) — les valeurs secrètes ne sont jamais incluses dans aucune réponse.
• Les opérations nécessitant une confirmation utilisent l'élicitation lorsque disponible. Lorsqu'une action d'écriture ou d'exécution présente un risque medium_write, high_write ou destructive, harness_create, harness_update, harness_delete et harness_execute tentent une élicitation MCP avant de procéder (voir Élicitation). Les actions à faible risque (read, low_write — par exemple pipeline.create, pipeline.update, hql_query.run) se déroulent silencieusement sans invite.
• Le risque moyen et supérieur échoue en mode fermé. Si la confirmation ne peut pas être obtenue pour les opérations medium_write, high_write ou destructive, elles sont bloquées au lieu d'être exécutées à l'aveugle. Remplacez avec HARNESS_AUTO_APPROVE_RISK pour les flux de travail autonomes.
• CORS restreint à la même origine. Le transport HTTP n'autorise que les requêtes de même origine, empêchant les attaques CSRF de sites malveillants ciblant le serveur MCP sur localhost.
• Limitation du débit HTTP. Le transport HTTP applique 60 requêtes par minute par IP pour empêcher l'inondation de requêtes.
• Limitation du débit API. Le client API Harness applique une limite de 10 requêtes/seconde pour éviter d'atteindre les limites de débit en amont.
• Limites de pagination appliquées. Les requêtes de liste sont plafonnées à 10 000 éléments au total et 100 par page pour éviter l'épuisement de la mémoire.
• Nouvelles tentatives avec backoff. Les échecs transitoires (HTTP 429, 5xx) sont réessayés avec un backoff exponentiel et une gigue.
• Liaison localhost. Le transport HTTP se lie à 127.0.0.1 par défaut — non accessible depuis le réseau.
• Aucune journalisation stdout. Tous les journaux vont vers stderr pour éviter de corrompre le transport JSON-RPC stdio.

Compétences complémentaires

Le serveur MCP Harness s'associe bien avec Harness Skills — une collection de compétences Claude Code prêtes à l'emploi (commandes slash) conçues pour les flux de travail Harness courants. Installez-les aux côtés de ce serveur MCP pour bénéficier d'automatisations de haut niveau comme /deploy, /rollback, /triage et plus encore, sans écrire d'invites personnalisées.

Dépannage et pièges courants

Symptôme	Cause probable	Que faire
HARNESS_ACCOUNT_ID is required when the API key does not include an account ID segment...	La clé API n'est pas dans un format pris en charge au niveau du compte (pat.<accountId>... ou sat.<accountId>...), donc l'ID de compte ne peut pas être déduit	Définir HARNESS_ACCOUNT_ID explicitement
Unknown transport: "..." au démarrage	Argument CLI de transport non pris en charge	Utiliser uniquement stdio ou http
Invalid HARNESS_TOOLSETS: ... au démarrage	Un ou plusieurs noms d'ensembles d'outils ne sont pas reconnus	Utiliser uniquement les noms de Filtrage des ensembles d'outils (correspondance exacte)
HTTP mcp-session-id header is required...	Une requête de session a été envoyée sans en-tête de session	Envoyer initialize d'abord, puis inclure mcp-session-id sur POST/GET/DELETE /mcp
HTTP Session not found...	Session expirée après MCP_SESSION_TTL_MS millisecondes d'inactivité ou déjà fermée	Relancer initialize pour créer une nouvelle session, puis réessayer avec le nouvel en-tête
HTTP 405 Method Not Allowed sur /mcp	Méthode non prise en charge pour le point de terminaison MCP	Utiliser uniquement POST, GET, DELETE ou OPTIONS
HTTP Invalid request	Corps JSON invalide ou corps de requête dépassant HARNESS_MAX_BODY_SIZE_MB	Valider la taille/forme de la charge utile JSON ; augmenter HARNESS_MAX_BODY_SIZE_MB si nécessaire
Unknown resource_type "..." des outils	Le type de ressource est mal orthographié ou filtré via HARNESS_TOOLSETS	Appeler harness_describe (avec search_term facultatif) pour découvrir les types valides
Missing required field "... for path parameter ..."	Un appel au niveau projet/organisation manque d'identifiants	Définir HARNESS_ORG/HARNESS_PROJECT ou passer org_id/project_id par appel d'outil
resource_scope "org" requires org_id... ou resource_scope "project" requires project_id...	Une ressource multi-portée a été forcée à la portée organisation/projet sans suffisamment d'identifiants	Passer les org_id/project_id manquants, configurer HARNESS_ORG/HARNESS_PROJECT, ou utiliser resource_scope: "account" lorsque pris en charge
Read-only mode is enabled ... operations are not allowed	HARNESS_READ_ONLY=true bloque la création/mise à jour/suppression/exécution	Définir HARNESS_READ_ONLY=false si des opérations d'écriture sont prévues
L'exécution du pipeline échoue avant le vol avec des entrées requises non résolues	Les inputs fournis ne couvraient pas les espaces réservés d'exécution requis	Récupérer runtime_input_template, fournir les clés simples manquantes, ou utiliser input_set_ids pour les entrées structurelles
La forme abrégée CI du pipeline (branch, tag, pr_number, commit_sha) ne s'est pas appliquée	inputs.build était déjà fourni, donc l'expansion abrégée a été intentionnellement ignorée	Supprimer inputs.build pour utiliser l'expansion abrégée, ou conserver la structure complète explicite build
L'exécution du pipeline a chargé la mauvaise révision YAML	La définition du pipeline est stockée dans Git et l'exécution n'a pas spécifié la branche de pipeline souhaitée	Passer params.pipeline_branch sur l'action run ; cela correspond à Harness branch
wait: true a renvoyé _wait.error	Le déclencheur du pipeline a réussi, mais l'interrogation côté serveur a échoué	Revérifier le execution_id avec harness_get(resource_type="execution", ...) avant de décider de relancer
wait: true a renvoyé execution_timed_out: true	L'exécution n'a pas atteint un statut terminal avant wait_timeout_seconds	Utiliser le execution_id renvoyé pour revérifier le statut ; attendre un statut terminal avant d'exécuter harness_diagnose
Les journaux d'exécution sont vides ou les téléchargements de blobs renvoient 403	Les URL de blobs de journaux hébergés par Harness nécessitent le chemin client/auth Harness configuré, en particulier pour les hôtes internes ou auto-gérés	Garder HARNESS_BASE_URL pointé vers l'hôte Harness cible et utiliser harness_get(resource_type="execution_log", ...) ou harness_diagnose(..., include_logs=true) plutôt que de contourner le client MCP
Operation declined by user / Operation cancelled by user	L'utilisateur a refusé ou annulé la boîte de dialogue de confirmation d'élicitation — faisant autorité	Vérifier les détails de l'opération avec l'utilisateur ; confirm: true ne contourne pas un refus explicite. L'utilisateur doit accepter l'invite
Operation blocked: the client could not surface a usable confirmation prompt	Le client manque de support d'élicitation, elicitInput a échoué, ou a renvoyé une acceptation dégénérée	Réessayer avec confirm: true pour l'automatisation non interactive, ou utiliser un client prenant en charge l'élicitation
body.template_yaml (or body.yaml) is required pour la création/mise à jour de modèles	Les API de modèles attendent une charge utile YAML complète	Fournir la chaîne complète template_yaml dans body ; pour les suppressions, passer version_label pour supprimer une version (omettre pour supprimer toutes les versions)
HARNESS_BASE_URL must use HTTPS au démarrage	HARNESS_BASE_URL est défini sur une URL HTTP	Utiliser HTTPS, ou définir HARNESS_ALLOW_HTTP=true pour le développement local

Licence

MIT