Douze routes composent l’API HTTP de Meilisearch : création d’index, ajout de documents, suppression, réglages, et bien sûr recherche. Un serveur MCP construit pour un agent conversationnel n’a besoin d’en exposer qu’une seule, parfois deux si l’on compte l’auto-complétion. Le reste ne doit tout simplement pas exister côté agent.
Cette contrainte n’est pas une posture prudente parmi d’autres : c’est la condition pour qu’un moteur de recherche reste un moteur de recherche, et ne devienne pas une porte d’entrée vers la base de données. Voici comment poser cette frontière concrètement, avec un serveur MCP minimal branché sur une instance Meilisearch existante.
Le problème : une clé API qui en fait trop
Par défaut, la clé « master » de Meilisearch permet tout : créer un index, y injecter des documents, le supprimer, changer ses réglages de pertinence. Si cette clé se retrouve, même indirectement, dans la configuration d’un outil MCP consommé par un agent, l’agent hérite de tous ces pouvoirs — qu’il les utilise ou non n’a aucune importance, la possibilité suffit à créer un risque.
La bonne pratique consiste à créer une clé restreinte via l’endpoint POST /keys, en limitant explicitement les actions autorisées et les index concernés. Meilisearch permet de définir des clés scoped avec un champ actions qui n’accepte que ["search"], et un champ indexes qui liste précisément les index accessibles.
Ce que l’outil MCP doit exposer, et ce qu’il doit taire
Un outil MCP nommé par exemple rechercher_produits ne doit accepter en entrée qu’une requête textuelle et, éventuellement, des filtres prédéfinis (catégorie, fourchette de prix). Il ne doit jamais accepter de paramètres libres qui ressembleraient à des filtres Meilisearch bruts, sous peine de laisser l’agent reconstruire des requêtes non prévues.
- Le nom de l’index reste codé côté serveur, jamais transmis par l’agent.
- Les champs retournés sont une liste blanche, définie par
attributesToRetrieve. - Les champs internes (coûts, marges, identifiants fournisseurs) sont exclus du tout, même en lecture.
Construire le serveur MCP minimal
Voici un exemple simplifié d’implémentation, côté PHP, d’un serveur MCP exposant un unique outil de recherche vers Meilisearch. Le point important n’est pas la syntaxe exacte du protocole mais la discipline appliquée à la clé et aux champs retournés.
function outil_rechercher_produits( array $arguments ): array {
$requete = sanitize_text_field( $arguments['query'] ?? '' );
$reponse = wp_remote_post(
'https://meilisearch.exemple.fr/indexes/produits/search',
array(
'headers' => array(
'Authorization' => 'Bearer ' . MEILISEARCH_CLE_LECTURE,
'Content-Type' => 'application/json',
),
'body' => wp_json_encode(
array(
'q' => $requete,
'attributesToRetrieve' => array( 'titre', 'prix', 'url' ),
'limit' => 10,
)
),
)
);
if ( is_wp_error( $reponse ) ) {
return array( 'erreur' => 'recherche indisponible' );
}
return json_decode( wp_remote_retrieve_body( $reponse ), true );
}La constante MEILISEARCH_CLE_LECTURE pointe vers la clé restreinte créée plus haut, jamais vers la clé maître. Cette séparation, à elle seule, transforme un risque potentiel de fuite ou de manipulation de l’index en un simple accès de consultation, sans conséquence en cas de mauvaise utilisation par l’agent.
Variantes selon le niveau de filtrage souhaité
Certains projets ont besoin d’aller plus loin que la simple lecture-écriture. Voici trois variantes rencontrées sur des projets réels, du plus permissif au plus strict.
| Variante | Ce que l’agent peut faire | Cas d’usage typique |
|---|---|---|
| Recherche libre | Interroger tout le catalogue public | Assistant d’achat sur un site marchand |
| Recherche filtrée par rôle | Voir uniquement les produits liés à un partenaire | Portail B2B multi-comptes |
| Recherche à réponses pré-calculées | Recevoir des résumés déjà formatés, sans accès brut aux champs | FAQ dynamique avec contenu sensible |
Dans les trois cas, la clé d’API reste dédiée à la recherche et ne permet jamais l’écriture. C’est ce socle qui rend chaque variante sûre par construction, indépendamment de la sophistication du prompt ou du modèle utilisé côté agent.
Ce qui arrive quand on saute cette étape
Sur un projet observé récemment, l’intégration initiale utilisait directement la clé maître « pour aller plus vite en phase de test », avec l’intention de la restreindre plus tard. Cette étape n’a jamais eu lieu avant la mise en production, simplement parce que personne n’était officiellement responsable de la reprendre après la livraison.
Une clé d’API créée « temporairement » avec des droits larges devient, dans les faits, la clé de production : personne ne revient dessus tant que rien ne casse.
La correction a consisté à créer une clé scoped, à la déployer, puis à révoquer l’ancienne clé maître exposée côté agent. Aucune régression n’a été constatée côté fonctionnalités, ce qui confirme que la restriction n’enlève rien d’utile à l’usage réel — elle retire seulement ce qui n’aurait jamais dû être accessible.
En résumé
Exposer Meilisearch à un agent IA via MCP ne pose pas de problème en soi : le moteur est pensé pour la recherche, pas pour la modification à la volée. Le risque vient uniquement d’une confusion entre clé de développement et clé de production, ou d’une paresse à définir un scope précis. Deux réflexes suffisent à l’éviter : une clé actions: ["search"] dédiée, et une liste blanche de champs retournés. Le reste — filtrage par rôle, réponses pré-calculées — n’est qu’un raffinement optionnel au-dessus de ce socle.
