🚀 Création d'une application PHP MCP pour publier des articles Darkwood

Source: Dev.to

Les grands modèles de langage sont déjà performants pour la génération de texte.
Ce qui manque encore, dans de nombreux projets, c’est une méthode simple pour transformer cette génération en un véritable flux de travail : rédiger un brouillon, le relire, le corriger, le publier et l’intégrer de manière intuitive dans une application cliente d’IA.

C’est précisément là que les applications MCP (Model‑Centered Programming) deviennent intéressantes.

Pourquoi les applications MCP sont importantes

Les applications MCP ajoutent quelque chose de plus pratique : elles permettent à un outil d’intégrer sa propre interface utilisateur embarquée.
Cela modifie considérablement le modèle d’interaction :

• Au lieu de se contenter de renvoyer du texte, un outil peut désormais ouvrir une interface dédiée au sein du système hôte.
• Cette interface peut afficher l’état des entrées, présenter les résultats, guider l’utilisateur tout au long d’un flux et déclencher des appels d’outils supplémentaires.
• L’outil cesse d’être une simple fonction distante et se comporte davantage comme une interface d’application à part entière.

Dans un flux de travail éditorial, ce modèle est bien plus adapté que le simple texte brut.

Cas d’utilisation : publication d’un article de blog Darkwood

Cette application MCP est utilisée pour faciliter la publication d’un article de blog sur Darkwood. Le flux de travail se compose de deux étapes principales :

1. GenerateDraft – produit une ébauche initiale à partir d’un sujet ou d’un contexte.
2. PublishDraft – gère le processus de publication.

Note : si le brouillon n’est pas encore satisfaisant, le processus peut se poursuivre. Il est possible de revenir en arrière, de corriger ou de réviser avant de tenter une nouvelle publication. Cette boucle d’itération est cruciale, car la première ébauche est souvent trop brouillonne, trop générique, trop longue, ou ne correspond pas à l’intention éditoriale.

Un serveur MCP, plusieurs façons de l’utiliser

Le serveur peut être utilisé via différents transports :

Remarque : lorsqu’une application MCP est impliquée, l’interface utilisateur communique avec l’hôte via un autre canal JSON‑RPC (généralement postMessage). Il y a donc deux niveaux de communication :

• hôte ↔ serveur via MCP,
• interface UI ↔ hôte via postMessage.

Cycle de vie d’une connexion MCP

1. Initialisation – L’hôte initialise la connexion et découvre les capacités du serveur.
2. Discovery – L’hôte liste les outils et les ressources disponibles.
3. Invocation – Lorsqu’un utilisateur déclenche un outil, l’hôte appelle cet outil sur le serveur.
4. Ressource UI – Si l’outil possède une ressource d’interface (ui://…), l’hôte charge cette ressource et l’affiche dans une iframe isolée.
5. Interaction – L’application MCP devient interactive : elle reçoit les données saisies, affiche les résultats et déclenche des actions complémentaires via l’hôte.

Dans le flux de travail Darkwood, cela signifie que l’utilisateur (ou l’assistant) peut passer de la génération d’ébauches à la publication, puis revenir dans une boucle de correction, le tout sans quitter le modèle d’interaction MCP.

Architecture

Vue d’ensemble

+-------------------+        +-------------------+
|   Hôte MCP        |  |   Serveur PHP     |
| (client)          |        | (MCP server)      |
+-------------------+        +-------------------+
        ^                               ^
        |                               |
        | JSON‑RPC (Stdio / HTTP)       |
        |                               |
        v                               v
+-------------------+        +-------------------+
|   Interface UI   |  |   Ressources UI   |
+-------------------+        +-------------------+

Un hôte MCP se connecte au serveur PHP.
Cette séparation permet de conserver une interface utilisateur portable sur les hôtes compatibles tout en préservant un contrat MCP propre côté serveur.

Transports détaillés

Stdio

• Idéal pour les extensions Claude Desktop.
• L’hôte lance le serveur, échange des messages JSON‑RPC via stdin/stdout.
• Simple, local et efficace lorsque le client gère les processus.

HTTP

• Utile pour les hôtes orientés navigateur, les tests locaux ou toute configuration où une limite HTTP est plus pratique.
• Deux modes d’implémentation :
  1. Processus dédié et persistant (ex. : flow worker).
  2. Serveur HTTP classique (ex. : Symfony Server).

Important : « prend en charge HTTP » ne signifie pas automatiquement « prend en charge le même modèle d’exécution partout ».

• Avec Stdio ou un worker HTTP persistant, on peut envisager un processus persistant, ouvrant la voie à des fonctionnalités asynchrones, des boucles d’événements et une orchestration continue.
• Avec Symfony Server, chaque requête est traitée dans un cycle HTTP synchrone : plus simple à mettre en œuvre, mais l’orchestration du workflow doit être déléguée (ex. : couche Flow ou coordination externe).

Gestion du flux éditorial

1. Initialisation – L’hôte gère le transport, le rendu et la liaison entre l’interface utilisateur et le serveur.
2. Orchestration – La couche Flow orchestre les flux de travail lorsqu’ils impliquent plusieurs actions et transitions d’état.

Les flux éditoriaux impliquent souvent plus d’une action et plus d’une transition d’état ; la couche Flow assure que ces étapes sont correctement coordonnées.

Conclusion

Les applications MCP offrent une interface utilisateur intégrée qui transforme la simple génération de texte en un flux de travail complet : rédaction, révision, publication et itération.
Dans le contexte de Darkwood, cela permet de :

• Générer rapidement une première ébauche.
• Itérer facilement (correction, révision) sans quitter l’environnement MCP.
• Publier le contenu final de manière fluide.

En combinant les transports Stdio et HTTP avec une architecture claire (hôte ↔ serveur ↔ UI), les développeurs peuvent créer des expériences éditoriales riches, réactives et facilement extensibles.

Cette conception est‑elle efficace pour les flux de travail de publication ?

Il ne s’agit pas d’un simple appel de fonction, ni d’une application back‑office complète.
Elle nécessite une structure suffisante pour gérer l’état et les décisions, tout en restant assez légère pour être déclenchée par une conversation avec une IA.

C’est précisément pourquoi les applications MCP sont parfaitement adaptées ici.

Rôles des différentes couches

• Interface de l’outil – fournit au modèle une surface d’interaction.
• Interface utilisateur – offre à l’utilisateur ou au client une vue contrôlée du flux de travail.
• Orchestration du flux – permet au système de gérer les transitions en plusieurs étapes.

Cette combinaison est efficace car chaque couche reste ciblée :

• le modèle décide quand utiliser l’outil,
• le projet n’est pas seulement un prototype local ou une démo pour navigateur ; il peut être installé dans Claude et utilisé comme une véritable intégration d’outil.

Configuration

1. Manifeste de l’extension – définit comment Claude lance le serveur.
2. Du prototype à l’outil éditorial réel – le projet définit déjà une forme réutilisable pour les outils éditoriaux :
   • un outil pour produire un brouillon,
   • une fois cette structure en place, l’amélioration du flux de travail devient beaucoup plus simple :
     • optimisation de la qualité de la génération,
     • enrichissement des métadonnées de publication,
     • ajout de validations,
     • intégration d’un véritable CMS.

Le contrat entre l’hébergeur, l’interface utilisateur et le serveur reste stable.

Open source

https://github.com/darkwood-com/darkwood-publish-article-mcp-apps

Conclusion

Dans le cas de Darkwood, le plus intéressant n’est pas que PHP puisse communiquer avec MCP.
Le plus intéressant est qu’un serveur PHP MCP puisse désormais servir de backend à une petite application éditoriale, accessible depuis un client d’IA, avec à la fois :

• la sémantique de l’outil,
• une interface utilisateur intégrée.

Cela fait passer l’intégration de « le modèle peut appeler une fonction » à « le modèle peut participer à un flux de travail de publication contrôlé ».
Et c’est un endroit bien plus utile.

Sources

• Démarrage rapide des applications MCP – README.md
• Architecture MVP des php‑mcp‑apps – php-mcp-apps-mvp-architecture.md