Un serveur MCP unique qui expose plusieurs sites d’un même multisite

Un réseau WordPress multisite de neuf sous-sites, un par filiale régionale d’une même enseigne, souhaitait ouvrir un accès agent pour la génération de rapports de contenu et la recherche d’articles. La question posée dès le départ : faut-il un serveur MCP par sous-site, ou un serveur unique capable de s’adresser au bon sous-site selon la demande ? Nous avons retenu la seconde option, pour des raisons de maintenance autant que de cohérence d’architecture.

Cet article détaille comment ce routage a été construit, et pourquoi la question de l’identifiant de site explicite dans chaque appel d’outil s’est révélée plus délicate qu’elle n’en avait l’air au départ.

Pourquoi un serveur unique plutôt que neuf

Neuf serveurs MCP distincts auraient signifié neuf déploiements à surveiller, neuf schémas d’outils à maintenir en synchronisation, et un risque réel de divergence progressive entre eux au fil des mises à jour. Un serveur unique, connecté au réseau multisite via l’API de commutation de site propre à WordPress, permet de maintenir une seule base de code pour l’ensemble des outils exposés.

Le routage par identifiant de sous-site

Chaque outil du serveur MCP reçoit systématiquement un paramètre site_id obligatoire, jamais déduit implicitement du contexte de connexion. C’est le point le plus important de cette architecture : un agent qui omettrait ce paramètre reçoit une erreur de validation, plutôt qu’une réponse portant par défaut sur le site principal du réseau.

{
  "name": "search_articles",
  "inputSchema": {
    "type": "object",
    "properties": {
      "site_id": { "type": "integer", "description": "Identifiant du sous-site cible dans le réseau" },
      "mot_cle": { "type": "string" }
    },
    "required": ["site_id", "mot_cle"]
  }
}

Côté PHP, chaque appel bascule explicitement de contexte avec switch_to_blog(), exécute la requête, puis revient systématiquement au contexte d’origine avec restore_current_blog(), même en cas d’erreur intermédiaire.

function agence_search_articles( $site_id, $mot_cle ) {
    if ( ! get_site( $site_id ) ) {
        return new WP_Error( 'site_invalide', 'Sous-site introuvable dans le réseau.' );
    }

    switch_to_blog( $site_id );

    $articles = get_posts( array(
        's'         => $mot_cle,
        'post_type' => 'post',
    ) );

    $resultat = array_map( function ( $p ) {
        return array( 'id' => $p->ID, 'titre' => get_the_title( $p ) );
    }, $articles );

    restore_current_blog();

    return $resultat;
}

Le piège du contexte oublié

Lors des premiers tests, une erreur survenue en cours de requête (par exemple un dépassement de délai sur une recherche trop large) empêchait restore_current_blog() d’être appelé, laissant le contexte du serveur bloqué sur le mauvais sous-site pour les appels suivants. La correction a consisté à envelopper systématiquement chaque appel dans un bloc garantissant le retour au contexte d’origine, y compris en cas d’exception.

function agence_avec_contexte_site( $site_id, callable $action ) {
    switch_to_blog( $site_id );
    try {
        return $action();
    } finally {
        restore_current_blog();
    }
}

Limiter l’accès d’un agent à un sous-ensemble de sites

Certains agents (par exemple un outil de reporting utilisé par le siège) ont besoin d’accéder à l’ensemble des neuf sous-sites. D’autres, utilisés par une équipe régionale, ne doivent voir que leur propre sous-site. Cette restriction est appliquée à l’authentification du serveur, avant même l’exécution de l’outil : le jeton d’accès de l’agent porte la liste des identifiants de sous-sites autorisés, vérifiée à chaque appel.

Profil d’agent	Sous-sites accessibles
Reporting siège	Les neuf sous-sites
Équipe régionale	Un seul sous-site, le sien

Le paramètre site_id obligatoire dans chaque outil n’est pas qu’une question de routage technique : c’est aussi le point où l’on vérifie que l’agent a réellement le droit de consulter ce sous-site précis.

En résumé

Un serveur MCP unique pour un réseau multisite évite la duplication de code et de configuration entre sous-sites, à condition d’imposer un identifiant de site explicite dans chaque outil plutôt que de le déduire du contexte de connexion, et de garantir que le contexte de sous-site est toujours restauré après chaque appel, même en cas d’erreur. Ce sujet ne traite pas la maintenance pilotée par agent en général, abordée séparément : il porte uniquement sur ce que le multisite change dans la conception du serveur lui-même.