3 articles tagués avec « mcp »

Dans notre précédent blogpost, nous avons expliqué comment utiliser la CLI cwc comme agent web et comment l'utiliser dans les fonctionnalités CWAI comme le chat ou le moteur FaaS.

Dans ce blogpost, nous allons voir comment utiliser la CLI cwc comme agent web en tant que webhook Gitlab déclenché par les commentaires d'issues et des mots-clés.

Commençons par configurer cwc avec les variables d'environnement suivantes :

• CWC_AGENT_NAME : le nom de l'agent qui sera utilisé comme déclencheur (ex. : cwc-prod pour être déclenché par des commentaires contenant !cwc-prod dans les issues Gitlab)
• CWC_GITLAB_TOKEN : un token Gitlab avec la permission de publier des commentaires sur les issues
• CWC_GITLAB_BASE_URL : l'URL de l'instance Gitlab (ex. : https://gitlab.cwcloud.tech)

Vous pouvez également utiliser la commande cwc configure comme ceci :

$ cwc configure set agent_name cwc-prod
$ cwc configure set gitlab_token <your_gitlab_token>
$ cwc configure set gitlab_base_url https://gitlab.cwcloud.tech

Ensuite, vous devrez configurer le webhook dans Gitlab comme ceci :

Comme vous pouvez le voir, nous avons configuré l'endpoint /gitlab et nous avons aussi défini un header Authorization attendu par notre reverse proxy pour server l'agent. Néammoins, l'agent web supporte aussi le webhook secret de Gitlab pour l'authentification (c'est optionnel, mais faites attention à bien configurer une authentification d'une manière ou d'une autre).

Et donc, voici ce que nous obtenons dans les issues Gitlab quand nous commentons !{agent name} :

En conclusion, les utilisateurs peuvent travailler et intervenir en production tout en restant dans le tableau central des tickets.

Dans notre blogpost précédent, nous avions présenté le serveur MCP et l'agent IA CWCloud. Nous avions expliqué comment nous avons implémenté le serveur MCP et comment l'utiliser avec un agent IA en mode CLI.

Dans cet article, nous allons voir cette fois comment utiliser cwc comme adaptateur web externe compatible avec l'API CWAI.

Tout d'abord, voici comment démarrer la CLI cwc en tant qu'agent web :

$ cwc ai web-agent

On peut aussi préciser le port et l'adresse d'écoute :

$ cwc ai web-agent -a 0.0.0.0 -p 8081 -s http://localhost:8080/mcp

Ensuite, on peut envoyer une requête HTTP POST à l'agent web comme ceci :

$ curl -X POST http://localhost:8081 -H "Content-Type: application/json" -d '{ "settings": { "max_tokens": 500 }, "message": "Hello"}'

L'agent web répondra ainsi (en respectant le contrat de l'adaptateur externe) :

{
  "status": "ok",
  "message": "Hello! How can I assist you today?",
  "usage": {
    "prompt_tokens": 8,
    "completion_tokens": 10,
    "total_tokens": 18
  }
}

Pour héberger la CLI comme serveur MCP et agent web en même temps, voici un exemple de fichier docker compose :

services:
  cwc_mcp:
    image: "rg.fr-par.scw.cloud/cwcloud-ce-u7u1q0/cwc:1.19.13"
    restart: always
    container_name: cwc_mcp
    env_file:
      - .env.cwc
    volumes:
      - "/etc/ssl/certs/ca-bundle.crt:/etc/ssl/certs/ca-bundle.crt:ro"
      - "/etc/ssl/certs/ca-bundle.trust.crt:/etc/ssl/certs/ca-bundle.trust.crt:ro"
    command: ["ai", "mcp", "-l", "0.0.0.0", "-p", "8080"]
    networks:
      - cwc_network
  cwc_agent:
    image: "rg.fr-par.scw.cloud/cwcloud-ce-u7u1q0/cwc:1.19.13"
    restart: always
    container_name: cwc_agent
    env_file:
      - .env.cwc
    volumes:
      - "/etc/ssl/certs/ca-bundle.crt:/etc/ssl/certs/ca-bundle.crt:ro"
      - "/etc/ssl/certs/ca-bundle.trust.crt:/etc/ssl/certs/ca-bundle.trust.crt:ro"
    command: ["ai", "web-agent", "-a", "0.0.0.0", "-p", "8081", "-s", "http://cwc_mcp:8080"]
    ports:
        - "8081:8081"
    networks:
      - cwc_network

networks:
  cwc_network:
    driver: bridge

Dans .env.cwc, vous pouvez définir toutes les variables d'environnement nécessaires pour la CLI cwc, comme la clé API et le modèle par défaut à utiliser. Vous pouvez vous référer à cette documentation pour plus de détails.

On peut ensuite ajouter l'agent web comme adaptateur externe :

Puis l'utiliser avec le chat de CWAI :

Et bien sûr, vous pourrez aussi l'utiliser dans le moteur FaaS comme ceci :

Et voilà comment utiliser l'agent web cwc comme adaptateur externe pour CWAI !

Vous vous demandez peut-être pourquoi nous parlons toujours de MCP¹ en 2026 alors que beaucoup de monde affirme que ce n'est plus utile parce que les agents IA peuvent facilement utiliser la CLI ce qui évite d'avoir à faire une double maintenance.

C'est la principale raison pour laquelle il nous a fallu si longtemps pour livrer un serveur MCP : nous maintenons déjà la CLI cwc² et ne voulions pas dupliquer le travail en maintenant à la fois une CLI et un serveur MCP.

Initialement, nous avions essayé de regrouper toutes les fonctionnalités de la CLI dans des packages Go qui pourraient être inclus dans le serveur MCP. Cependant, nous nous sommes vite rendu compte que c'était beaucoup de travail et nécessiterait de maintenir les deux artefacts à chaque fois que nous ajouterions une nouvelle fonctionnalité.

Après quelques tentatives, nous nous sommes rendu compte que nous pouvions générer dynamiquement le serveur MCP avec les définitions d'outils directement à partir de la CLI, qui est implémentée en Go et Cobra. De cette façon, nous pouvions calculer toutes les définitions d'outils à partir de la documentation de la CLI et générer le serveur MCP à la volée sans maintenir deux codebases séparés.

Encore mieux : les développeurs peuvent ajouter des sous-commandes et le serveur MCP les utilisera dynamiquement sans aucun travail supplémentaire.

Et voilà, cela fonctionne simplement en lançant cette sous-commande pour démarrer le serveur MCP :

$ cwc ai mcp
Starting cwc MCP server on http://127.0.0.1:8080/mcp

Evidemment, vous pouvez changer le port et l'adresse d'écoute comme ceci :

$ cwc ai mcp -p 8081 -l 0.0.0.0
Starting cwc MCP server on http://0.0.0.0:8081/mcp

Et nous avons un outil list_mcp_dynamic_tools qui liste tous les outils disponibles sur le serveur.

Maintenant vous vous demandez peut-être "OK, c'est bien, mais pourquoi devrais-je utiliser un serveur MCP au lieu de la CLI directement avec un agent ?". Selon nous, MCP et agents ne sont pas antinomiques et peuvent être utilisés ensemble. Nous pensons que fournir des outils MCP pour vos agents nécessite moins d'effort de votre côté qu'implémenter un agent qui appelle la CLI et en parse la sortie.

Bien entendu, nous fournissons aussi un moyen de créer des agents capables d'appeler le serveur MCP avec la commande cwc ai agent :

$ cwc ai agent -p "your prompt"

La commande fonctionne avec gpt4omini d'OpenAI par défaut mais supporte également tous les modèles d'OpenAI, Anthropic, Google Gemini, Deepseek ou OpenRouter (qui fournit les modèles open-source de Meta) :

$ cwc ai agent -p "your prompt" --provider openrouter --model "meta-llama/llama-3.3-70b-instruct"

Voici une démo sur comment utiliser le serveur MCP avec un agent pour lister les projets et les instances ainsi que les outils MCP disponibles :

Notes :

• Vous pouvez faire des demandes dans une autre langue, par exemple en Français, comme montré dans la démo.
• Vous devez exposer le serveur MCP dans un terminal séparé. Cela vous permet de cibler un serveur MCP distant en utilisant le drapeau -s (nous ajouterons l'authentification plus tard) :

  cwc ai agent -p "list me the projects" -s "http://127.0.0.1:8081/mcp"
  
• La documentation complète est disponible ici.

La cli fourni également un mode interactif/REPL³ pour l'agent qui permet d'exécuter plusieurs prompts dans la même session (avec le flag -i ou --interactive) :

$ cwc ai agent -i
Using model: gpt-4o-mini (provider: openai)
Interactive mode enabled. Type your prompt and press Enter.
Type 'exit' or 'quit' to leave.
> get me the monitors
> list me all the available MCP tools

Démonstration :

Conclusion : on anticipe le fait que les agents IA sont le futur visage du platform engineering. Il nous paraît donc important dans ce contexte que ceux-ci soient embarqués dans votre CLI et privilégient d'invoquer des commandes répétables et compréhensibles (afin de les faire confirmer par l'humain) plutôt que des tools MCP opaques qui seraient directement associés à la définition de vos endpoints d'API ou SDK (qui eux ne sont généralement pas répétables facilement).

En outre, le fait d'avoir choisi de proposer un serveur MCP et un Agent dans le même binaire que la CLI mais qui s'exécutent dans des processus différents permet de proposer des agents fonctionnants d'exécution simple qui fonctionnent avec les modèles les moins puissants et moins chers du marché tels que gpt-4o-mini, mistral-small, gemini-1.5-flash, deepseek (le moins cher) ou encore llama auto-hébergé. En effet, ces agents n'ont pas besoin de beaucoup de capacité de raisonnement pour interpréter du langage et le transformer en invocation de ligne de commande en sélectionant le bon tool MCP. Mais cela permet également de pouvoir invoquer ce même serveur MCP dans des agents plus complexes qui fonctionnent avec des modèles plus puissants qui produiraient du raisonnement et des workflows de troubleshooting plus avancés couplé avec éventuellement d'autres serveurs MCP pour les outils d'observabilité par exemple.

On ajoutera probablement bien d'autres fonctionnalités donc restez à l'écoute !