# Un premier prototype de serveur MCP pour exposer Algolia à un agent

> Deux semaines après la publication du protocole, la startup Cherchemoi a construit un prototype connectant un agent à son index de recherche Algolia. Retour sur ses limites, encore nombreuses à ce stade.

- Auteur : WordPress Développement
- Publié le : 2024-12-04
- Mis à jour le : 2024-12-04
- Catégorie : IA &amp; MCP
- URL : https://www.wpmoderne.fr/ia-mcp/prototype-serveur-mcp-algolia/

## L’essentiel

- Le protocole étant tout jeune, les bibliothèques clientes restaient rudimentaires
- Le prototype ne gérait qu'un seul index Algolia à la fois
- Aucune authentification fine n'était encore envisageable à ce stade

Trois jours de développement, une seule fonction exposée, aucun mécanisme d'authentification digne de ce nom : le premier prototype de serveur MCP construit par la startup Cherchemoi pour connecter un agent conversationnel à son index de recherche Algolia n'avait rien d'un produit fini, et c'était précisément l'objectif de cet exercice.

L'idée de départ était simple : le protocole MCP, publié quelques semaines plus tôt, promettait de standardiser la façon dont un agent découvre et appelle un outil externe. Plutôt que d'attendre une maturité que personne ne pouvait garantir, l'équipe technique a préféré construire un prototype jetable pour se confronter concrètement aux limites du protocole à son tout premier stade, avant de décider si un investissement plus sérieux avait du sens.

## Ce que le prototype exposait

Une seule fonction, `searchProducts`, acceptant un terme de recherche en paramètre et interrogeant l'index Algolia principal de la plateforme pour renvoyer les dix meilleurs résultats. Aucune autre capacité (filtrage par catégorie, tri par prix, recherche à facettes) n'a été implémentée à ce stade, l'objectif étant de vérifier le fonctionnement de bout en bout du protocole sur un cas le plus simple possible, pas de couvrir tous les usages réels de la recherche du site.

```
{
  "tool": "searchProducts",
  "description": "Recherche des produits dans l index Algolia principal",
  "parameters": {
    "type": "object",
    "properties": { "query": { "type": "string" } },
    "required": ["query"]
  }
}
```

## Les limites rencontrées, propres à ce stade précoce

La première difficulté a été l'absence quasi totale de documentation d'usage au-delà de la spécification technique elle-même, encore jeune de quelques semaines. Chaque question d'implémentation demandait de relire directement la spécification plutôt que de trouver une réponse dans un tutoriel existant, faute d'exemples publiés par d'autres équipes ayant déjà tenté l'exercice.

> L'essentiel à retenir : Le protocole étant tout jeune, les bibliothèques clientes restaient rudimentaires ; Le prototype ne gérait qu'un seul index Algolia à la fois ; Aucune authentification fine n'était encore envisageable à ce stade

La deuxième limite tenait à l'absence de mécanisme d'authentification robuste envisageable à ce stade du protocole : le prototype tournait sur un environnement de test isolé, sans exposition publique, précisément parce qu'aucune solution satisfaisante n'existait encore pour restreindre l'accès à un serveur MCP de façon fiable. Cette question a été volontairement reportée à une itération future, une fois le protocole et son écosystème d'outils plus matures.

### Ce qui a fonctionné malgré tout

- Le principe de découverte d'outil par le client, qui a permis à l'agent de test d'identifier et d'appeler correctement la fonction exposée sans configuration manuelle côté client.
- La structure des paramètres, suffisamment simple pour ne poser aucune difficulté d'interprétation par l'agent.
- Le temps de réponse global, l'appel à Algolia restant la partie la plus rapide de toute la chaîne.

### Ce qui reste à explorer

1. La gestion de plusieurs index Algolia distincts, pour couvrir par exemple un index produits et un index articles de blog séparés.
2. Un mécanisme d'authentification qui permettrait d'envisager une exposition au-delà d'un environnement de test isolé.
3. La gestion des erreurs Algolia (index absent, quota dépassé) de façon lisible pour l'agent appelant.

> Sur un protocole aussi jeune, le prototype n'a pas vocation à être robuste : il sert à vérifier qu'on a bien compris le principe, avant que l'écosystème n'ait eu le temps de proposer de meilleures pratiques.

## Ce que ce prototype ne couvre pas

La sécurité de ce serveur MCP, volontairement limitée à un environnement de test fermé, n'a pas fait l'objet d'une analyse approfondie dans le cadre de cet exercice : le sujet mérite un traitement à part entière, une fois que le protocole proposera des recommandations plus établies sur ce point précis.

## En résumé

Trois jours ont suffi pour vérifier qu'un agent pouvait effectivement découvrir et appeler un outil exposé via MCP relié à Algolia, une preuve de concept encourageante malgré un périmètre volontairement restreint. Les limites rencontrées tiennent moins au principe du protocole qu'à la jeunesse de son écosystème, encore dépourvu de bibliothèques matures et de bonnes pratiques éprouvées à peine deux semaines après sa publication.
