Connecter Ghost CMS à Copilot Studio

Partie 1 d'une série : configuration MCP en HTTP → agent Copilot Studio. Les prochains articles couvriront le BYO MCP Server (Agents 365, en préversion) et les connecteurs personnalisés Power Apps.

Un MCP HTTP pour Ghost CMS

Cette plateforme de blog est présentement basée sur Ghost CMS.

À l'ère de l'IA où tester, essayer et utiliser l'IA pour s'aider devient monnaie courante, pourquoi ne pas essayer avec mon blog?
Alors, il fallait mettre en place un MCP — un serveur Model Context Protocol pour Ghost CMS.
Avec GitHub Copilot CLI, connecté en stdio et une clé Admin API Ghost comme identifiant par utilisateur; ça existe déjà. Cette configuration est parfaite sur un poste local : un seul processus, une session locale, une clé dans une variable d'environnement.

Mais utiliser ce même MCP local pour créer des articles, gérer les tags, parcourir les membres, lire les newsletters depuis un environnement Microsoft 365 (pour qu'un agent puisse à la fois s'appuyer sur des documents SharePoint, des conversations Teams et gérer un blog Ghost), le stdio n'était plus une option.
Copilot Studio, Microsoft 365 Copilot et tout autre runtime d'agent hébergé dans le cloud ont besoin d'un serveur joignable depuis Internet — ce qui impose un protocole de communication en HTTP.

GitHub - Laul0/ghost-mcp: A Model Context Protocol (MCP) server for interacting with Ghost CMS through LLM interfaces like Claude. Allow you to control your Ghost blog by simply asking Claude etc.

A Model Context Protocol (MCP) server for interacting with Ghost CMS through LLM interfaces like Claude. Allow you to control your Ghost blog by simply asking Claude etc. - Laul0/ghost-mcp

GitHubLaul0

Configurer le serveur Ghost MCP en HTTP

Le serveur est distribué sous forme d'image Docker:

services:
  ghost-mcp:
    image: ghcr.io/laul0/ghost-mcp:latest
    environment:
      - GHOST_API_URL=https://your-ghost-site.example
      - MCP_TRANSPORT=http
      - MCP_PORT=3000
      - MCP_HTTP_PATH=/
    ports:
      - "3000:3000"
    restart: unless-stopped

docker compose pull
docker compose up -d

Vérification de l'état : http://<votre-hôte>:3000/health doit renvoyer ok.

Au-delà de localhost, placer un reverse proxy (Nginx, Caddy, Traefik) devant pour avoir une connexion HTTPS via une Autorité de certification (ex: Let’s Encrypt), car Copilot Studio et Microsoft 365 n'accepteront de se connecter qu'avec une URL public sécurisée https://.

[info]Important

L'URL doit être joignable publiquement. Il y a en réalité deux liaisons réseau distinctes, et les deux doivent utiliser un nom de domaine public, jamais un nom de service Docker interne :

• Copilot Studio → serveur MCP : Copilot Studio et Microsoft 365 Copilot s'exécutent dans le cloud — ils ne peuvent résoudre ni un nom d'hôte interne à Docker, ni une adresse localhost/127.0.0.1, ni une machine uniquement accessible depuis votre LAN/VPN. Il faut le point de terminaison public, en https://, derrière votre reverse proxy.
• Conteneur MCP → application Ghost (GHOST_API_URL) : c'est le piège dans lequel je suis moi-même tombé. Si votre docker-compose.yml définit un service Ghost nommé, par exemple, ghost-app, il est tentant de configurer GHOST_API_URL=http://ghost-app:2368 en s'appuyant sur le réseau Docker interne, puisque les deux conteneurs tournent côte à côte. Dans la pratique, ça ne fonctionne pas de façon fiable : il faut renseigner l'URL publique réelle du blog, https://blog.mydomain.com, même quand le conteneur MCP et le conteneur Ghost sont dans le même docker-compose.yml.

Un conteneur, une instance Ghost — par conception

GHOST_API_URL est figé dans le conteneur au moment du déploiement via une variable d'environnement. C'est voulu : le serveur MCP est lié en permanence à une seule instance Ghost. Même si chaque client fournit son propre identifiant Ghost, aucun client — Copilot CLI, Claude ou Copilot Studio — ne peut rediriger les appels d'outils vers une autre instance Ghost en passant une URL différente. i L'identifiant contrôle qui peut agir et ce qu'il est autorisé à faire sur ce blog ; la configuration du conteneur contrôle quelle instance de Ghost doit être utilisée. Si vous gérez plusieurs sites Ghost, déployez un conteneur Ghost MCP (avec sa propre URL publique) par site, plutôt que de partager un seul conteneur entre plusieurs sites.

Conserver un accès par utilisateur

C'est le choix de conception qui compte le plus : le conteneur ne détient jamais d'identifiant Ghost partagé. Seule la variable GHOST_API_URL vit dans l'environnement du conteneur. Chaque client MCP — Copilot CLI, Claude, VS Code, ou plus tard Copilot Studio — doit envoyer sa propre clé Ghost via un en-tête de requête :

Cet identifiant doit être une clé Admin API d'intégration personnalisée (la paire id:secret obtenue depuis Ghost Admin → Réglages → Intégrations), car c'est ce que @tryghost/admin-api utilise pour signer les requêtes vers Ghost.

Une nuance mérite d'être soulignée : Ghost dispose aussi des Staff Access Tokens — des JWT de courte durée émis lors de la connexion d'un membre de l'équipe à Ghost Admin. Ceux-ci préservent une attribution exacte par utilisateur et le respect des rôles, mais ils ne sont pas compatibles avec la bibliothèque cliente Admin API utilisée par ce serveur MCP (qui a besoin du secret brut pour signer ses propres jetons).
Le modèle pratique pour un accès « par personne » est le suivant : chaque utilisateur crée sa propre intégration personnalisée dans Ghost, nommée à son nom, et utilise cette clé. Vous obtenez ainsi une traçabilité individuelle (created_by affiche cette intégration), même si les clés d'intégration personnalisée ne respectent pas les frontières de rôles Ghost (Contributeur/Auteur/Éditeur/Administrateur) comme le ferait une session utilisateur réelle.

Une fois la clé en main, tester depuis Copilot CLI tient en une ligne :

copilot mcp add ghost-mcp \
  --type http \
  --url https://your-domain.example/ \
  --header "Authorization=Bearer <id:secret>" \
  --header "x-ghost-api-version=v5.0" \
  --tools "*"

Une fois cela fonctionnel, le même point d’accès HTTP est prêt à être réutilisé par Microsoft 365.

Connecter Ghost CMS dans Microsoft 365

Utiliser Copilot Studio est un moyen simple et accessible pour configurer un serveur MCP et pour pouvoir l'utiliser au travers d'un agent

En préversion nous avons la possibilité de faire du Bring Your Own (BYO) MCP Server via Microsoft Agents 365 et le CLI Agents 365 - l'ajout de ce type de fonctionnalité requiert une validation par un administrateur — ce sujet sera couvert dans un prochain article une fois testé de bout en bout.
Il existe aussi une voie via un connecteur personnalisé Power Apps pour brancher un serveur MCP (OpenAPI + x-ms-agentic-protocol: mcp-streamable-1.0) dans Power Platform, que j'explorerai également séparément.

Pour cet article, le chemin le plus direct et le plus rapide est Copilot Studio, qui dispose d'un assistant d'intégration MCP intégré, prévu exactement pour ce scénario : connecter un agent à un serveur MCP existant via Streamable HTTP.

Étape 1 — Créer (ou modifier) votre agent Copilot Studio

Dans Copilot Studio, créer un nouvel agent (ou modifier un existant) — c'est cet agent qui gérera votre instance Ghost CMS et, à terme, permettra d’utiliser les documents SharePoint et d’autres types de données.

[info]Important
Lors de la création d'un agent, sélectionner Orchestration Standard (ne consomme aucun crédit) ou Processus Entreprise (crédits IA - GitHub Copilot)

Étape 2 — Ajouter Ghost MCP comme outil

1- Depuis le panneau de configuration de l'agent, cliquer sur Outils (Tools).

2- Sélectionner Ajouter → Model Context Protocol (MCP). L'assistant d'intégration MCP s'ouvre.

3- Renseigner :

• Nom du serveur : blog-mcp
• Description du serveur : quelque chose d'explicite, comme « Gérer le blog Ghost : créer/modifier/lire/supprimer des articles, tags, membres, newsletters, offres, webhooks, etc. » L'orchestrateur utilise cette description pour décider quand appeler le serveur, soyez donc précis.
• URL du serveur : https://your-domain.example/ — le point de terminaison HTTPS public, accessible depuis Internet.
• Type de paramètre : l'identifiant Ghost étant une clé Admin API statique, sélectionnez En-tête (Header). Copilot Studio ne prend en charge que le transport Streamable HTTP (le SSE a été déprécié en août 2025).

• Nom de l'en-tête : Authorization
• Valeur clé: Bearer your-id:your-secret

4- Sélectionner Ajouter, puis créer une nouvelle connexion. Dans le champ Authorization, répéter la valeur clé (Bearer your-id:your-secret) et cliquer sur Créer.

5- Cliquer sur Ajouter.

[note]Note
Copilot Studio appellera tools/list sur le conteneur en cours d'exécution et affichera tous les outils Ghost MCP : posts, tags, members, newsletters, offers, tiers, invites, roles, users, webhooks. Vous pouvez tous les activer, ou restreindre l'agent à un sous-ensemble plus sûr (par exemple, seulement posts_* et tags_* si vous ne voulez pas que l'agent touche aux membres ou aux webhooks).

Étape 3 — Tester dans Copilot Studio

Il est possible d'utiliser la prévisualisation pour essayer quelques prompts :

• « Liste mes 5 derniers articles en brouillon sur le blog »
• « Crée un article en brouillon intitulé   'Test de Ghost MCP depuis Copilot Studio'»
• « Quels tags existent sur mon blog ? »

Si tout est correctement connecté, vous verrez l'agent appeler les outils posts_browse, posts_add ou tags_browse et renvoyer des données réelles de votre instance Ghost 🥳🚀

✨ Nouveau, étape intermédiaire

Il est aussi possible de lancer des tests unitaires pour évaluer votre agent !
Créer plusieurs conversations et indiquer les messages attendus.

Lancer l'évaluation et vous obtiendrez un score:

Étape 4 — Publier et combiner avec les données Microsoft 365

Une fois l'outil fonctionnel, publier l'agent sur Microsoft Teams et/ou le chat Microsoft 365 Copilot. C'est vraiment là que se trouve le bénéfice : le même agent peut désormais aussi recevoir les connecteurs SharePoint et OneDrive (ou une source de connaissances pointant vers une bibliothèque de documents), pour pouvoir demander par exemple « Prends les résultats de tests d'aujourd'hui sur SharePoint et rédige un article qui les résume » — une seule conversation, un seul agent, couvrant à la fois Ghost et les documents/données provenant de Microsoft 365 🚀

Une fois publié, il sera alors possible de surveiller votre agent:

• Nombre de réactions
• Nombre d'utilisateurs actifs
• Crédits Copilot si ce n'est pas un agent standard ❤️🙏🏻
• etc.

Et ensuite

Cet article couvre une première façon de mettre en place un MCP personnalisé depuis Copilot Studio : Ghost MCP en mode HTTP + l'assistant d'intégration MCP de Copilot Studio. Deux articles suivront :

1. BYO MCP Server (préversion) — enregistrer Ghost MCP au niveau du Tenant via le CLI Agents 365 et le centre d'administration Microsoft 365, pour qu'il soit disponible pour n'importe quel agent sans configuration additionnelle.
2. Connecteur personnalisé Power Apps — encapsuler le même point de terminaison MCP en tant que connecteur personnalisé basé sur OpenAPI pour des scénarios Power Platform (flux Power Automate, application Power Apps).

Aviez-vous déjà expérimenté cette solution ? Sinon, êtes-vous prêt à essayer ?
Quels sont vos cas d'usages?

• Tags:
• Copilot
• MCP
• Ghost Blog
• Microsoft 365
• Copilot Studio
• Docker
• Getting Started
• GitHub