Parcourir le catalogue de services et préparer un déploiement

Le catalogue métier est la liste des serveurs MCP que la plateforme sait décrire, regrouper en profils et suivre. Ce tutoriel parcourt ce qui fonctionne aujourd'hui (consulter, filtrer, lire les profils, connaître l'état) et dit sans détour où s'arrête l'automatisation : le déploiement d'un service par l'API est en sommeil et répond 503.

Ce qui marche, ce qui est en sommeil

Opération	Route (préfixe `/api/v1/mcp/catalog-business`)	État
Lister le catalogue	`GET /`	actif
Détail d'un serveur	`GET /{id}`	actif
Lister les profils	`GET /profiles`	actif
Serveurs prouvés opérationnels	`GET /deployed`	actif
État d'un serveur	`GET /{id}/status`	actif (disponibilité au registre)
Déployer un serveur	`POST /{id}/deploy`	503, en sommeil
Déployer un profil	`POST /profiles/{name}/deploy`	503, en sommeil
Démarrer / arrêter / redémarrer	`POST /{id}/start`, `/stop`, `/restart`	503, en sommeil
Profil de sécurité	`GET /{id}/security`	503, en sommeil
Enregistrer des secrets	`POST /{id}/secrets`	503, en sommeil

Les opérations en sommeil dépendent du pilotage de Podman par le backend, pas encore branché. Tant qu'il ne l'est pas, elles répondent 503 avec l'en-tête Retry-After et un corps FEATURE_PENDING, jamais un faux succès. Les opérations de cycle de vie sont de plus réservées aux rôles admin et owner : tout autre rôle reçoit 403. Seule exception, GET /{id}/security : ouverte à tout utilisateur connecté, elle répond 503.

Toutes les routes exigent un jeton de session ($JWT).

Prérequis

Chatbotaurus installé et fonctionnel (voir Installation).
Un jeton de session (Swagger, section Authentification), rangé dans la variable JWT. Pour tenter un déploiement, un compte de rôle admin ou owner.
curl et jq pour les commandes ci-dessous, lancées contre le backend local http://localhost:3000 (sur un déploiement, remplacez cette adresse par celle de votre API).

Étape 1 : consulter le catalogue

# Tous les serveurs
curl -s -H "Authorization: Bearer $JWT" \
  http://localhost:3000/api/v1/mcp/catalog-business \
  | jq '.servers[] | {id, name, category, status}'

# Filtrer par catégorie
curl -s -H "Authorization: Bearer $JWT" \
  "http://localhost:3000/api/v1/mcp/catalog-business?category=CRM%20%26%20ERP" | jq .total

# Le détail d'un serveur
curl -s -H "Authorization: Bearer $JWT" \
  http://localhost:3000/api/v1/mcp/catalog-business/odoo | jq .

La réponse est de la forme { "servers": [...], "total": N }. Chaque entrée porte id, name, description, category, provider, country, license, status, tags et version. Le champ status vaut available ou coming-soon : le catalogue décrit plus de serveurs qu'il n'en livre, et ce champ dit lesquels sont prêts. Un identifiant inconnu rend 404.

Étape 2 : lire les profils

Un profil est un regroupement de serveurs pour un usage. La réponse est de la forme { "profiles": [...] }.

curl -s -H "Authorization: Bearer $JWT" \
  http://localhost:3000/api/v1/mcp/catalog-business/profiles | jq .

Il existe quatre profils : Solo (l'ERP seul), Starter (cinq serveurs : ERP, automatisation, analytique, fichiers, modèle local), Business (douze serveurs, avec agenda, documents, visioconférence, GED, supervision et voix) et Enterprise (tous les serveurs du fichier de profils). Les identifiants de serveurs d'un profil sont ceux du fichier de profils, tenu côté serveur : ils portent le préfixe mcp- et le suffixe -eu, et diffèrent des id de la liste du catalogue (par exemple odoo).

Étape 3 : savoir ce qui est réellement opérationnel

curl -s -H "Authorization: Bearer $JWT" \
  http://localhost:3000/api/v1/mcp/catalog-business/deployed | jq .

Cette route ne rend pas un inventaire de conteneurs. Elle rend la liste des serveurs prouvés opérationnels, sous la forme d'un tableau JSON d'identifiants : un identifiant n'y figure que si un outil de lecture a rendu des données réelles lors d'une vérification en direct. Elle sert de source unique à l'application, qui affiche donc le même état « déployé » sur toutes ses pages.

curl -s -H "Authorization: Bearer $JWT" \
  http://localhost:3000/api/v1/mcp/catalog-business/odoo/status | jq .

L'état d'un serveur dit s'il est enregistré dans le registre (available ou not_registered), s'il est prouvé opérationnel, et que l'état d'exécution du conteneur est inconnu tant que le pilotage Podman n'est pas branché (runtime.known: false).

Étape 4 : tenter un déploiement

curl -i -X POST -H "Authorization: Bearer $JWT" \
  http://localhost:3000/api/v1/mcp/catalog-business/odoo/deploy

Avec un compte admin ou owner, la réponse attendue aujourd'hui est :

HTTP/1.1 503 Service Unavailable
Retry-After: 86400

{ "error": { "code": "FEATURE_PENDING", ... }, "feature_pending": "catalog_business" }

Avec un autre rôle, c'est 403. Ce 503 n'est pas une panne : c'est l'état documenté de la fonction. Arrêtez-vous là côté API.

Comment déployer un service en attendant

Les services du catalogue destinés au plan client sont décrits dans le fichier Compose du plan client, où chaque serveur MCP est un service nommé mcp-*. Le déploiement passe par ce plan, avec podman-compose (avec un tiret), décrit dans Déploiement avec Podman. Les secrets ne passent pas par l'API du catalogue : ils sont enregistrés en identifiants du locataire (page /credentials), comme dans le tutoriel Connecter Odoo.

Dans l'application

La page MCP > Serveurs Business (/mcp/servers/business) présente le même catalogue, avec l'état « déployé » tiré de la route /deployed. La page de passerelle par secteur (/mcp/gateways/business) regroupe les serveurs par métier. Ce sont des pages de l'application, pas des routes d'API.

Voir aussi

Routes du catalogue métier : toutes les routes du catalogue, lecture et cycle de vie, avec leurs réponses
Déploiement avec Podman : déployer les plans avec podman-compose en attendant l'automatisation
Architecture Chatbotaurus : deux plans, règle de nommage et crates du workspace
MCP et Orchestrateur : les pages de l'application qui présentent ce catalogue
Tarification et offres : offres, déploiement assisté des outils métier et quotas

Raccourcis clavier