Si vous gérez de nombreux sites WordPress, vous êtes sans cesse à la recherche d’un moyen plus simple de réduire le temps que vous passez à accéder aux tableaux de bord et à cliquer sur une série de boutons.
Les MCP (Model Context Protocols) font beaucoup parler d’eux ces derniers temps, et nous avons décidé d’explorer comment les MCP, associés à l’API Kinsta, pourraient aider une agence à gérer un si grand nombre de sites web.
Dans cet article, nous vous présentons un exemple concret de création d’un serveur MCP qui connecte des assistants IA comme Claude à l’API Kinsta pour gérer les tâches d’hébergement WordPress que les agences effectuent déjà au quotidien.
Ce que nous construisons
Nous construisons un serveur MCP qui met à disposition un ensemble d’outils, afin que les assistants IA puissent effectuer des actions telles que :
- Répertorier tous les sites WordPress de votre compte
- Afficher les environnements d’un site spécifique
- Vider le cache dans un environnement donné
- Cloner un site existant pour en créer un nouveau
- Voir les extensions et les thèmes obsolètes ou vulnérables
- Lancer les mises à jour des extensions sur des environnements spécifiques
Une fois le serveur configuré, il est connecté à un hôte/client MCP (dans ce cas, Claude for Desktop) :
Remarquez comment il appelle divers outils puis renvoie la réponse suivante :
Pour commencer
Avant de vous plonger dans le code, il est utile de comprendre quelques notions de base sur la façon dont MCP s’intègre dans cette configuration.
Un serveur MCP se situe entre un assistant IA et une API existante. Il ne remplace pas l’API ni ne modifie son fonctionnement. Au lieu de cela, il expose un ensemble d’outils que l’IA peut appeler en cas de besoin. Chaque outil correspond à une action spécifique, comme répertorier des sites ou vider le cache de votre site.
Lorsque vous posez une question à un assistant IA, celui-ci détermine si l’un de ces outils est pertinent. Si c’est le cas, l’assistant appelle l’outil via le serveur MCP, le serveur communique avec l’API, et le résultat est renvoyé sous forme de simple réponse. Rien ne s’exécute automatiquement sans votre accord, et seuls les outils que vous exposez sont disponibles.
Dans cet exemple, le serveur MCP communique avec l’API Kinsta et expose un ensemble limité d’actions d’hébergement WordPress. Aucune interface utilisateur personnalisée, aucune automatisation en arrière-plan ni aucune configuration spéciale de l’IA n’est nécessaire.
Prérequis
Pour suivre, vous devez disposer de quelques éléments :
- Une installation stable de Node.js
- Une connaissance de base de TypeScript
- Un compte Kinsta avec l’accès à l’API activé
- Votre clé API Kinsta et votre identifiant d’entreprise
Vous n’zavez pas besoin d’expérience préalable avec MCP, et vous n’avez pas besoin de créer ou d’entraîner un modèle d’IA. On se concentre uniquement sur l’interconnexion d’outils existants.
Configuration du projet
Commencez par créer un nouveau répertoire pour le projet et initialiser une application Node.js :
mkdir kinsta-mcp
cd kinsta-mcp
npm init -yEnsuite, installez le SDK MCP et le petit ensemble de dépendances que nous utilisons :
npm install @modelcontextprotocol/sdk zod@3
npm install -D typescript @types/nodeCréez une structure de projet de base :
mkdir src
touch src/index.tsMettez ensuite à jour votre fichier package.json pour que Node puisse exécuter le serveur compilé :
{
"name": "kinsta-mcp-server",
"version": "1.0.0",
"description": "Serveur MCP pour gérer des sites WordPress via l'API Kinsta",
"type": "module",
"scripts": {
"build": "tsc"
},
"dependencies": {
"@modelcontextprotocol/sdk": "^1.0.0",
"zod": "^3.24.0"
},
"devDependencies": {
"@types/node": "^22.0.0",
"typescript": "^5.0.0"
}
}Enfin, ajoutez un fichier tsconfig.json à la racine du projet :
{
"compilerOptions": {
"target": "ES2022",
"module": "Node16",
"moduleResolution": "Node16",
"outDir": "./build",
"rootDir": "./src",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true
},
"include": ["src/**/*"],
"exclude": ["node_modules"]
}Une fois ça en place, vous êtes prêt à commencer à construire le serveur MCP lui-même.
Construire le serveur MCP
Maintenant que le projet est configuré, il est temps de construire le serveur MCP lui-même.
On commence par importer les paquets nécessaires et créer l’instance du serveur. Ensuite, on ajoute un petit utilitaire pour communiquer avec l’API. Après ça, on enregistre les outils qui correspondent directement aux actions d’hébergement WordPress.
Importer les paquets et créer le serveur
Ouvrez src/index.ts et ajoute les importations suivantes en haut du fichier :
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";Cela fait trois choses :
McpServerest le serveur principal qui enregistre les outils et gère les requêtes provenant du client IAStdioServerTransportpermet au serveur de communiquer via des entrées/sorties standard, ce qui correspond au mode de connexion de la plupart des clients IA de bureauzodsert à définir et à valider les données d’entrée acceptées par chaque outil
Ensuite, définissez quelques constantes pour l’API et les identifiants :
const KINSTA_API_BASE = "https://api.kinsta.com/v2";
const KINSTA_API_KEY = process.env.KINSTA_API_KEY;
const KINSTA_COMPANY_ID = process.env.KINSTA_COMPANY_ID;Créez maintenant l’instance du serveur MCP :
const server = new McpServer({
name: "kinsta",
version: "1.0.0",
});Le nom correspond à la façon dont le serveur apparaît dans un client MCP. La version est facultative, mais utile une fois que vous commencez à itérer.
Ajouter une fonction d’aide pour les requêtes API
La plupart des outils que nous développons doivent effectuer des requêtes HTTP vers l’API. Plutôt que de répéter cette logique partout, crée une seule fonction d’aide. Ajoutez ceci sous la configuration du serveur :
async function kinstaRequest(
endpoint: string,
options: RequestInit = {}
): Promise {
const url = `${KINSTA_API_BASE}${endpoint}`;
const headers = {
Authorization: `Bearer ${KINSTA_API_KEY}`,
"Content-Type": "application/json",
...options.headers,
};
const response = await fetch(url, { ...options, headers });
if (!response.ok) {
const errorText = await response.text();
throw new Error(`Erreur API Kinsta (${response.status}): ${errorText}`);
}
return response.json() as Promise;
}Mise en œuvre de l’exécution des outils
Les outils sont la principale fonctionnalité exposée par un serveur MCP. Chaque outil est une fonction qu’un assistant IA peut appeler, avec votre accord, pour effectuer une tâche spécifique.
Sur ce serveur, chaque outil suit la même structure :
- Un nom d’outil (comme
list_sites) - Une brève description (cela aide l’assistant à savoir quand l’utiliser)
- Un schéma d’entrée (pour que l’outil ne s’exécute qu’avec des entrées valides)
- Une fonction de gestion (où on appelle l’API et on formate la sortie)
On formate les réponses en texte brut exprès. Les assistants IA fonctionnent mieux quand les outils renvoient une sortie claire et lisible plutôt que de balancer du JSON brut.
Outil 1 : Lister les sites
Cet outil récupère tous les sites WordPress associés à votre compte d’entreprise. C’est généralement la première chose dont vous avez besoin lorsque vous travaillez avec plusieurs sites, car la plupart des autres actions commencent par un identifiant de site.
La réponse de l’API comprend des informations de base sur chaque site, nous définissons donc une structure simple pour travailler avec :
interface Site {
id: string;
name: string;
display_name: string;
status: string;
site_labels: Array;
}
interface ListSitesResponse {
company: {
sites: Site[];
};
}Une fois cela en place, on peut enregistrer l’outil :
server.registerTool(
"list_sites",
{
description:
"Récupère tous les sites WordPress de ton entreprise. Renvoie les identifiants, les noms et le statut des sites.",
inputSchema: {},
},
async () => {
const data = await kinstaRequest(
`/sites?company=${KINSTA_COMPANY_ID}`
);
const sites = data.company.sites;
if (!sites || sites.length === 0) {
return {
content: [
{ type: "text", text: "Aucun site trouvé pour cette entreprise." }
],
};
}
const siteList = sites
.map((site) => {
const labels =
site.site_labels?.map((l) => l.name).join(", ") || "none";
return `• ${site.display_name} (${site.name})
ID : ${site.id}
Statut : ${site.status}
Étiquettes : ${labels}`;
})
.join("\n\n");
return {
content: [
{
type: "text",
text: `Found ${sites.length} site(s):\n\n${siteList}`,
},
],
};
}
);Cet outil ne nécessite aucune entrée, donc le schéma d’entrée est vide. Dans le gestionnaire, on appelle l’API, on vérifie si le résultat est vide, puis on formate la réponse sous forme de texte lisible.
Au lieu de renvoyer du JSON brut, on renvoie un bref résumé qui fonctionne bien dans une interface de chat. Ça permet à un assistant IA de répondre facilement à des questions comme « Quels sites ais-je ? » ou « Montrez-moi tous mes sites WordPress » sans analyse supplémentaire.
Outil 2 : Obtenir les environnements
Une fois que vous avez un ID de site, l’étape suivante consiste généralement à vérifier ses environnements. Cet outil renvoie tous les environnements d’un site donné, y compris les environnements de production, de staging et de staging premium.
interface Environment {
id: string;
name: string;
display_name: string;
is_premium: boolean;
primaryDomain?: {
id: string;
name: string;
};
container_info?: {
php_engine_version: string;
};
}
interface GetEnvironmentsResponse {
site: {
environments: Environment[];
};
}Certains champs sont facultatifs, comme le domaine principal ou la version PHP, ils sont donc indiqués comme tels. L’outil lui-même ne prend que l’ID du site :
server.registerTool(
"get_environments",
{
description:
"Récupère les environnements (production, staging) pour un site spécifique. Nécessite l'ID du site.",
inputSchema: {
site_id: z.string().describe("L'ID du site pour lequel récupérer les environnements"),
},
},
async ({ site_id }) => {
const data = await kinstaRequest(
`/sites/${site_id}/environments`
);
const envs = data.site.environments;
if (!envs || envs.length === 0) {
return {
content: [
{ type: "text", text: "Aucun environnement trouvé pour ce site." }
],
};
}
const envList = envs
.map((env) => {
const domain = env.primaryDomain?.name || "Pas de domaine";
const php = env.container_info?.php_engine_version || "Inconnu";
const type = env.is_premium
? "Staging Premium"
: env.name === "live"
? "Live"
: "Staging";
return `• ${env.display_name} (${type})
ID: ${env.id}
Domaine: ${domain}
PHP: ${php}`;
})
.join("\n\n");
return {
content: [
{
type: "text",
text: `Environnements trouvés : ${envs.length}\n\n${envList}`,
},
],
};
}
);C’est généralement l’étape suivante avant des actions telles que vider le cache, cloner un site ou mettre à jour des extensions.
Outil 3 : Vider le cache du site
Vider le cache est une tâche de routine, mais c’est aussi une opération asynchrone. Quand vous la lancez, l’API répond immédiatement avec un ID d’opération, tandis que le vidage du cache se poursuit en arrière-plan.
Voici la définition du type et la fonction de l’outil :
interface OperationResponse {
operation_id: string;
message: string;
status: number;
}
server.registerTool(
"clear_site_cache",
{
description:
"Vider le cache d'un environnement de site. Nécessite l'ID de l'environnement.",
inputSchema: {
environment_id: z
.string()
.describe("L'ID de l'environnement pour lequel vider le cache"),
},
},
async ({ environment_id }) => {
const data = await kinstaRequest(
"/sites/tools/clear-cache",
{
method: "POST",
body: JSON.stringify({ environment_id }),
}
);
return {
content: [
{
type: "text",
text: `Vidéage du cache lancé !
ID de l'opération : ${data.operation_id}
Message : ${data.message}
Utilise get_operation_status pour vérifier la progression.`,
},
],
};
}
);Au lieu d’attendre que l’opération se termine, l’outil renvoie immédiatement l’ID de l’opération. Ça permet de garder l’interaction rapide et permet à l’assistant IA de faire un suivi plus tard si besoin.
Outil 4 : Cloner un site
Le clonage d’un site est l’une de ces actions que les agences utilisent tout le temps, surtout lorsqu’elles travaillent à partir de modèles ou qu’elles créent de nouveaux sites pour des clients. Au lieu de partir de zéro, vous prenez un environnement existant et vous créez un nouveau site à partir de celui-ci.
La réponse utilise la même structure d’opération que celle vue précédemment, il n’est donc pas nécessaire de la redéfinir. L’outil nécessite un nom d’affichage pour le nouveau site et l’ID de l’environnement à partir duquel effectuer le clonage :
server.registerTool(
"clone_site",
{
description:
"Clone un environnement de site existant pour créer un nouveau site. Idéal pour créer rapidement de nouveaux sites clients à partir d’un modèle.",
inputSchema: {
display_name: z
.string()
.describe("Nom du nouveau site cloné"),
source_env_id: z
.string()
.describe("L’ID de l’environnement à partir duquel cloner"),
},
},
async ({ display_name, source_env_id }) => {
const data = await kinstaRequest(
"/sites/clone",
{
method: "POST",
body: JSON.stringify({
company: KINSTA_COMPANY_ID,
display_name,
source_env_id,
}),
}
);
return {
content: [
{
type: "text",
text: `Clonage du site lancé !
Nouveau site : ${display_name}
ID de l'opération : ${data.operation_id}
Message : ${data.message}
Utilise get_operation_status pour vérifier la progression.`,
},
],
};
}
);Cet outil est particulièrement utile lorsqu’il est associé à d’autres outils. Par exemple, un assistant IA peut cloner un site, puis immédiatement lister les environnements ou vérifier l’état des extensions une fois l’opération terminée.
Outil 5 : Obtenir l’état de l’opération
Comme certaines actions s’exécutent de manière asynchrone, nous avons besoin d’un moyen de vérifier leur progression. C’est à ça que sert cet outil.
interface OperationStatusResponse {
status?: number;
message?: string;
}
server.registerTool(
"get_operation_status",
{
description:
"Vérifier l'état d'une opération asynchrone (vidage du cache, clonage du site, etc.)",
inputSchema: {
operation_id: z
.string()
.describe("L'ID de l'opération à vérifier"),
},
},
async ({ operation_id }) => {
const response = await fetch(
`${KINSTA_API_BASE}/operations/${encodeURIComponent(operation_id)}`,
{
headers: {
Authorization: `Bearer ${KINSTA_API_KEY}`,
},
}
);
const data: OperationStatusResponse = await response.json();
if (response.status === 200) {
return {
content: [
{
type: "text",
text: `Opération terminée avec succès !
Message: ${data.message || "Opération terminée"}`,
},
],
};
}
if (response.status === 202) {
return {
content: [
{
type: "text",
text: `Opération toujours en cours...
Message : ${data.message || "Traitement en cours"}`,
},
],
};
}
return {
content: [
{
type: "text",
text: `État de l'opération : ${response.status}
Message : ${data.message || "Statut inconnu"}`,
},
],
};
}
);Outil n° 6 : Récupérer les plugins sur tous les sites
Quand vous gérez plusieurs sites WordPress, c’est souvent au niveau des extensions que les choses commencent à déraper. Cet outil résout ce problème en examinant les extensions à l’échelle de tout le compte d’entreprise, et non site par site.
L’API renvoie de nombreuses informations, notamment les environnements dans lesquels chaque extension est installée, si des mises à jour sont disponibles et si une version est signalée comme vulnérable. Pour exploiter ces données, on définit les formes suivantes :
interface PluginEnvironment {
id: string;
site_display_name: string;
display_name: string;
plugin_status: string;
plugin_update: string | null;
plugin_version: string;
is_plugin_version_vulnerable: boolean;
plugin_update_version: string | null;
}
interface Plugin {
name: string;
title: string;
latest_version: string | null;
is_latest_version_vulnerable: boolean;
environment_count: number;
update_count: number;
environments: PluginEnvironment[];
}
interface GetPluginsResponse {
company: {
plugins: {
total: number;
items: Plugin[];
};
};
}L’outil lui-même ne prend aucune entrée :
server.registerTool(
"get_plugins",
{
description:
"Récupère tous les plugins WordPress sur tous les sites. Indique quels plugins ont des mises à jour disponibles ou des failles de sécurité.",
inputSchema: {},
},
async () => {
const data = await kinstaRequest(
`/company/${KINSTA_COMPANY_ID}/wp-plugins`
);
const plugins = data.company.plugins.items;
if (!plugins || plugins.length === 0) {
return {
content: [
{ type: "text", text: "Aucun plugin trouvé." }
],
};
}
const sorted = [...plugins].sort(
(a, b) => b.update_count - a.update_count
);
const pluginList = sorted.slice(0, 20).map((plugin) => {
const status =
plugin.update_count > 0
? `⚠️ ${plugin.update_count} site(s) à mettre à jour`
: "✅ À jour";
const vulnerable =
plugin.is_latest_version_vulnerable ? " 🔴 VULNÉRABLE" : "";
return `• ${plugin.title} (${plugin.name})${vulnerable}
Dernière version : ${plugin.latest_version || "inconnue"}
Installé sur : ${plugin.environment_count} environnement(s)
${status}`;
}).join("\n\n");
const outdatedCount = plugins.filter(
(p) => p.update_count > 0
).length;
return {
content: [
{
type: "text",
text: `${data.company.plugins.total} plugins trouvés (${outdatedCount} ont des mises à jour disponibles):\n\n${pluginList}`,
},
],
};
}
);Outil 7 : Récupérer les thèmes sur tous les sites
Les thèmes ont des problèmes similaires à ceux des extensions, mais ils sont souvent vérifiés encore moins fréquemment. Cet outil fonctionne de la même manière que l’outil pour les extensions, mais se concentre plutôt sur les thèmes WordPress.
La structure de la réponse est identique à celle du point de terminaison des extensions, mais avec des champs spécifiques aux thèmes :
interface ThemeEnvironment {
id: string;
site_display_name: string;
display_name: string;
theme_status: string;
theme_update: string | null;
theme_version: string;
is_theme_version_vulnerable: boolean;
theme_update_version: string | null;
}
interface Theme {
name: string;
title: string;
latest_version: string | null;
is_latest_version_vulnerable: boolean;
nombre_d'environnements : nombre ;
nombre_de_mises_à_jour : nombre ;
environnements : ThemeEnvironment[];
}
interface GetThemesResponse {
entreprise : {
thèmes : {
total : nombre ;
éléments : Theme[];
};
};
}Outil 8 : Mettre à jour un plugin
Répertorier les problèmes est utile, mais il faut bien finir par les résoudre. Cet outil vous permet de mettre à jour une extension spécifique dans un environnement spécifique.
Le point de terminaison de mise à jour renvoie la même structure d’opération asynchrone que celle utilisée précédemment, on peut donc la passer. Voici la définition de l’outil :
server.registerTool(
"update_plugin",
{
description:
"Mettre à jour un plugin spécifique vers une nouvelle version sur un environnement de site.",
inputSchema: {
environment_id: z
.string()
.describe("L'ID de l'environnement où le plugin est installé"),
plugin_name: z
.string()
.describe("Le nom/slug du plugin (par ex., 'akismet', 'elementor')"),
update_version: z
.string()
.describe("La version vers laquelle mettre à jour (par ex., '5.3')"),
},
},
async ({ environment_id, plugin_name, update_version }) => {
const data = await kinstaRequest(
`/sites/environments/${environment_id}/plugins`,
{
method: "PUT",
body: JSON.stringify({
name: plugin_name,
update_version,
}),
}
);
return {
content: [
{
type: "text",
text: `Mise à jour du plugin lancée !
Plugin : ${plugin_name}
Version cible : ${update_version}
ID de l'opération : ${data.operation_id}
Message : ${data.message}
Utilise get_operation_status pour vérifier la progression.`,
},
],
};
}
);Tout comme l’effacement du cache et les clones de site, les mises à jour s’exécutent de manière asynchrone. Le fait de renvoyer l’ID de l’opération permet à l’assistant IA de suivre la progression au lieu de supposer que la mise à jour s’est terminée instantanément.
Lancer le serveur
Une fois tous les outils enregistrés, la dernière étape consiste à démarrer le serveur MCP et à le rendre accessible à un client IA.
Au bas de ton fichier, ajoutez la fonction main qui connecte le serveur à l’aide du transport STDIO:
async function main() {
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("Serveur Kinsta MCP fonctionnant sur stdio");
}
main().catch((error) => {
console.error("Erreur fatale :", error);
process.exit(1);
});Cela indique au serveur MCP d’écouter les requêtes via l’entrée et la sortie standard. Ça rend le serveur détectable par les clients de bureau compatibles MCP.
Un détail important ici, c’est la journalisation. Comme ce serveur communique via STDIO, tous les journaux doivent aller vers stderr. Écrire dans stdout peut interférer avec les messages MCP et rompre la connexion.
Ensuite, compilez le projet :
npm run buildCela compile les fichiers TypeScript dans le répertoire build et rend le point d’entrée exécutable.
Une fois la compilation terminée, le serveur est prêt à être lancé par un client MCP. Vous pouvez accéder au code complet sur GitHub.
Tester votre serveur avec Claude for Desktop
Pour utiliser votre serveur MCP, Claude for Desktop doit savoir comment le lancer. Ouvrez le fichier de configuration de Claude Desktop :
~/Library/Application Support/Claude/claude_desktop_config.jsonCréez le fichier s’il n’existe pas encore. Si vous utilisez VS Code, vous pouvez l’ouvrir directement depuis le terminal :
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsonDans le fichier, ajoutez votre serveur MCP sous la clé mcpServers. Par exemple :
{
"mcpServers": {
"kinsta": {
"command": "node",
"args": ["/ABSOLUTE/PATH/TO/mcp-server-demo-kinsta-api/build/index.js"],
"env": {
"KINSTA_API_KEY": "ta-clé-api-ici",
"KINSTA_COMPANY_ID": "ton-id-entreprise-ici"
}
}
}
}Cette configuration indique à Claude for Desktop qu’il existe un serveur MCP nommé kinsta, qu’il doit être lancé à l’aide de Node.js et que le point d’entrée est le fichier index.js compilé.
Assurez-vous que le chemin pointe vers le fichier compilé dans le répertoire build, et non vers la source TypeScript. Enregistrez le fichier et redémarrez Claude for Desktop.
Vérification de la connexion
Une fois Claude redémarré, ouvrez une nouvelle conversation. Cliquez sur l’icône à côté du champ de saisie, puis passez la souris sur « Connectors ». Votre serveur MCP devrait apparaître dans la liste.
Une fois le serveur connecté, vous pouvez commencer à l’utiliser immédiatement. Claude choisit l’outil à utiliser, transmet les données nécessaires et renvoie le résultat sous forme de texte brut.
Une autre façon d’utiliser les outils dont vous disposez déjà
Ce qui change actuellement, ce ne sont pas les outils sous-jacents. Les API restent des API. Les plateformes d’hébergement fonctionnent toujours de la même manière. Ce qui change, c’est la façon dont on interagit avec elles.
Les outils d’IA commencent à ressembler moins à des boîtes de dialogue et davantage à des interfaces. Ce serveur MCP est un petit exemple de cette évolution. Il n’introduit pas de nouvelles fonctionnalités. Il expose celles qui existent déjà d’une manière qui correspond à la façon dont les gens travaillent réellement.
La suite dépend de vous. Vous pouvez choisir de rester simple et en lecture seule. Vous pouvez ajouter davantage d’automatisation avec des validations et des garde-fous. Ou vous pouvez connecter ce même serveur à d’autres outils de votre flux de travail.
Lorsque vous explorez de nouveaux outils et flux de travail comme celui-ci, il est essentiel de disposer d’une base d’hébergement solide. La dernière chose que vous souhaitez, c’est de perdre du temps à gérer des temps d’arrêt ou des problèmes de performances au lieu de créer et d’améliorer vos sites.
Kinsta propose un hébergement infogéré pour WordPress qui garantit le fonctionnement fiable de vos sites, même lorsque vous n’êtes pas en ligne. Vous pouvez découvrir nos formules d’hébergement ou contacter notre équipe commerciale pour trouver celle qui vous convient le mieux.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
