npx @modelcontextprotocol/create-server wpm-reservations : cette commande suffit à générer le squelette d’un serveur MCP en Node.js, prêt à encapsuler les actions d’une extension de réservation WordPress pour les rendre invocables par un assistant conversationnel comme Claude. Le protocole MCP (Model Context Protocol), publié fin 2024 par Anthropic, a depuis été adopté par plusieurs assistants du marché comme langage commun pour parler aux outils externes.
Ce billet construit un serveur MCP indépendant, en dehors du cœur WordPress. Il ne traite pas de l’Abilities API native, qui suit une approche différente en intégrant directement la déclaration de capacités dans WordPress — un sujet couvert ailleurs.
Pourquoi un serveur à part plutôt qu’un plugin
Un serveur MCP est un processus indépendant qui communique par entrées/sorties standard ou par HTTP avec le client conversationnel. Il ne tourne pas dans le contexte d’exécution de WordPress : il appelle l’extension depuis l’extérieur, le plus souvent via la REST API existante, avec ses propres identifiants applicatifs. Cette séparation présente un avantage net : aucune modification du cœur de l’extension n’est nécessaire, et le serveur peut être arrêté ou redéployé sans toucher au site.
Choisir les trois actions à exposer
Sur une extension de réservation pour un cabinet de kinésithérapie, les fonctions candidates étaient nombreuses. Le choix s’est porté sur trois actions à fort intérêt conversationnel et à risque maîtrisé : consulter les créneaux disponibles, créer une réservation, annuler une réservation existante. La modification des tarifs ou la gestion des praticiens, plus sensibles, sont restées hors périmètre du serveur MCP.
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
const server = new Server({ name: "wpm-reservations", version: "1.0.0" });
server.tool(
"list_available_slots",
{
description: "Liste les créneaux disponibles pour une date donnée",
inputSchema: {
type: "object",
properties: { date: { type: "string", format: "date" } },
required: ["date"],
},
},
async ({ date }) => {
const res = await fetch(
`${WP_BASE_URL}/wp-json/wpm/v1/slots?date=${date}`,
{ headers: { Authorization: `Bearer ${WP_APP_TOKEN}` } }
);
return { content: [{ type: "text", text: await res.text() }] };
}
);
Créer et annuler : deux outils, deux niveaux de prudence
La création de réservation appelle une route REST déjà existante dans l’extension, protégée par un jeton d’application WordPress classique (Application Passwords, disponible depuis WordPress 5.6). L’annulation, en revanche, exige une confirmation supplémentaire côté serveur MCP : le tool refuse d’exécuter l’action si le paramètre confirm n’est pas explicitement à true, pour limiter les annulations accidentelles déclenchées par une reformulation ambiguë de l’utilisateur.
Authentification : ne jamais faire confiance au client conversationnel
Le serveur MCP maison conserve son propre jeton d’application WordPress, stocké en variable d’environnement, jamais transmis par le client. Toute action reste donc soumise aux permissions de ce compte de service, qui peut être restreint à un rôle dédié plutôt qu’à un compte administrateur complet.
WP_BASE_URL=https://cabinet-exemple.fr
WP_APP_TOKEN=xxxx xxxx xxxx xxxx xxxx xxxx
Ce qui a posé problème en test
- Un fuseau horaire mal géré entre le serveur MCP (en UTC) et l’extension (réglée sur
Europe/Paris), corrigé en normalisant systématiquement les dates côté serveur avant l’appel REST. - Des réponses REST trop verbeuses, renvoyées telles quelles au modèle : un filtrage des champs utiles a réduit sensiblement la taille du contexte transmis.
- Une absence de limitation de débit sur le serveur MCP lui-même, corrigée en ajoutant un compteur simple par session.
Un serveur MCP n’est jamais « juste un pont » : chaque outil exposé est une nouvelle surface d’action, à documenter et à limiter comme une API publique à part entière.
Notre verdict
Pour une extension déjà dotée d’une REST API propre, construire un serveur MCP minimal représente quelques heures de travail, largement absorbées par la définition précise des schémas d’entrée. La vraie décision de conception se situe en amont : choisir avec soin les actions exposées, plutôt que de céder à la tentation d’exposer l’intégralité de l’API existante.
