Écrire un serveur MCP et le connecter directement à un agent de production pour voir s’il fonctionne est une tentation compréhensible, mais elle rend le débogage bien plus difficile en cas de problème : impossible de savoir si l’erreur vient du serveur, du client, ou de la façon dont l’agent interprète la réponse. Ce tutoriel montre comment valider un serveur MCP avec un client de démonstration minimal, avant toute connexion à un agent capable d’actions réelles.
L’authentification du serveur MCP n’est pas traitée en détail ici, elle fait l’objet d’un autre article : ce tutoriel part du principe qu’un serveur simple, en local, est déjà accessible sans authentification pour la phase de test.
Étape 1 : préparer le serveur à tester
Nous partons d’un serveur MCP WordPress minimal exposant un seul outil, list_recent_posts, qui renvoie les cinq derniers articles publiés. C’est volontairement simple : l’objectif de ce tutoriel est la méthode de test, pas la complexité de l’outil.
function agence_list_recent_posts( $count = 5 ) {
$posts = get_posts( array(
'post_type' => 'post',
'post_status' => 'publish',
'posts_per_page' => min( (int) $count, 20 ),
) );
return array_map( function ( $p ) {
return array( 'id' => $p->ID, 'titre' => get_the_title( $p ) );
}, $posts );
}
Étape 2 : lancer le serveur en local
Le serveur écoute en local sur un port dédié, séparé du site WordPress principal pendant la phase de test, pour éviter toute confusion entre le trafic de test et le trafic réel du site.
$ wp-mcp-server start --port 8420 --config mcp-config.json
Serveur MCP démarré sur http://localhost:8420
Outils exposés : list_recent_posts (1)Étape 3 : se connecter avec un client de démo
Un client MCP de démonstration minimal permet d’envoyer une requête de découverte des outils, puis d’appeler chacun d’eux individuellement avec des paramètres choisis à la main, sans passer par un agent qui déciderait lui-même quoi appeler.
$ mcp-client connect http://localhost:8420
Connecté. Outils disponibles :
- list_recent_posts(count: integer)
$ mcp-client call list_recent_posts --count 3
{
"result": [
{ "id": 128, "titre": "Comprendre les hooks WordPress" },
{ "id": 124, "titre": "Optimiser les requêtes SQL" },
{ "id": 119, "titre": "Migrer vers PHP 8.3" }
]
}Étape 4 : tester les cas limites, pas seulement le cas idéal
C’est l’étape la plus souvent négligée. Un outil qui fonctionne avec des paramètres corrects doit aussi être testé avec des paramètres absents, hors limites, ou d’un mauvais type, pour vérifier que le serveur répond une erreur claire plutôt qu’un comportement indéfini.
- Appeler l’outil sans aucun paramètre, pour vérifier la valeur par défaut.
- Envoyer une valeur hors des bornes attendues (
count: 500) et vérifier qu’elle est plafonnée, pas ignorée silencieusement. - Envoyer un type incorrect (
count: "beaucoup") et vérifier qu’une erreur explicite est renvoyée. - Vérifier que la réponse, dans chaque cas, respecte bien le schéma de sortie déclaré.
$ mcp-client call list_recent_posts --count "beaucoup"
{
"error": {
"code": "invalid_params",
"message": "Le paramètre count doit être un entier."
}
}Étape 5 : ne connecter l’agent réel qu’après ces vérifications
Ce n’est qu’après avoir validé le comportement de chaque outil sur ses cas normaux et ses cas limites que nous ouvrons l’accès à un agent de production. À ce stade, si un comportement inattendu survient, on sait déjà qu’il ne vient pas d’un défaut du serveur lui-même, ce qui réduit considérablement le périmètre du débogage.
Un serveur MCP testé uniquement via l’agent final, c’est déboguer deux systèmes à la fois. Un client de démo permet d’en isoler un seul.
En résumé
Un client MCP de démonstration coûte quelques minutes à mettre en place et fait gagner un temps de débogage considérable dès qu’un comportement inattendu apparaît. Tester systématiquement les cas limites de chaque outil, pas seulement son cas d’usage idéal, avant toute connexion à un agent réel, reste la meilleure garantie contre les mauvaises surprises en production.
