excel-mcp-server : manipuler des classeurs Excel depuis un agent MCP

Le problème concret : des classeurs sans Excel

Un agent conversationnel qui doit produire un rapport au format .xlsx se heurte vite à un mur : sur un serveur Linux ou dans un conteneur, Excel n'existe pas. Le README annonce la promesse sans détour : un serveur MCP qui permet de manipuler des fichiers Excel sans Microsoft Excel installé. Le public visé n'est donc pas l'utilisateur qui ouvre un classeur à la main, mais l'agent qui doit en générer un, ou l'automatisation qui doit en modifier un, dans un environnement où seule la bibliothèque Python fait le travail. Le dépôt cible explicitement les intégrations avec des clients MCP comme Cursor, dont le bouton d'installation figure en tête du README. C'est un outil d'outillage d'agent, pas une suite bureautique.

Trois transports, deux modèles de fichiers

Le serveur accepte trois modes de communication : stdio, SSE (marqué déprécié dans le README) et streamable HTTP (recommandé pour le distant). Le choix du transport change la manière dont les chemins de fichiers sont résolus, et c'est le point le plus important de l'architecture. En stdio, chaque appel d'outil transporte son propre chemin : le serveur lit et écrit là où le client le lui demande, et EXCEL_FILES_PATH n'est pas nécessaire. En SSE et en streamable HTTP, le serveur est une ressource partagée : il faut définir EXCEL_FILES_PATH côté serveur, et les chemins envoyés par l'agent doivent être relatifs à ce répertoire. Le README précise que les chemins absolus et la traversée de répertoire sont rejetés. C'est une contrainte de sécurité assumée, et elle a un coût : un agent qui travaille en HTTP ne peut pas sortir de la racine configurée. Le port d'écoute passe par FASTMCP_PORT, avec 8017 par défaut. Le README donne deux exemples d'activation, un pour PowerShell et un pour Linux/macOS, avec EXCEL_FILES_PATH et FASTMCP_PORT définis ensemble.

Ce que le catalogue d'outils couvre réellement

Le README énumère les capacités : création, lecture et mise à jour de classeurs et de feuilles, formules, mise en forme, graphiques, tableaux croisés dynamiques, tableaux Excel, validation de plages et d'intégrité, copie et renommage de feuilles, styles de police, bordures, alignement, mise en forme conditionnelle. La liste est large, et c'est aussi ce qui doit rendre prudent : la documentation complète des outils renvoie à un fichier séparé, TOOLS.md, qui n'est pas inclus dans le matériel fourni. Impossible donc de vérifier ici la signature exacte des paramètres, les valeurs de retour, ou la façon dont les erreurs de plage sont rapportées. Ce que l'on peut dire, c'est que le serveur se présente comme une surface d'outils exposée à un modèle, donc chaque outil devient une action que l'agent peut déclencher. La granularité compte : un outil qui écrit une plage est plus facile à valider qu'un outil qui exécute une formule arbitraire. Sur ce point, le README ne tranche pas.

Mise en route : les commandes du README

Le chemin le plus court pour un usage local est `uvx excel-mcp-server stdio`, lancé via uv. Le README donne la configuration client correspondante, avec `command` positionné sur `uvx` et `args` sur `["excel-mcp-server", "stdio"]`. Pour un accès distant, on lance `uvx excel-mcp-server streamable-http` et le client se connecte à `http://localhost:8000/mcp`. Le mode SSE, déprécié, utilise `uvx excel-mcp-server sse` et l'URL `http://localhost:8000/sse`. Attention à un détail qui saute aux yeux : les exemples HTTP du README montrent le port 8000 dans les URL client, alors que FASTMCP_PORT est décrit avec une valeur par défaut de 8017. Le README ne commente pas cet écart. Si vous suivez les exemples à la lettre, vérifiez le port réellement écouté avant de conclure que la connexion échoue pour une autre raison. Pour le mode HTTP, l'exemple Linux/macOS est `EXCEL_FILES_PATH=/path/to/excel_files FASTMCP_PORT=8007 uvx excel-mcp-server streamable-http`.

Le cas où ce n'est pas le bon outil

Le serveur est un pont entre un agent et des fichiers, pas un moteur de calcul. Si votre besoin est de recalculer un modèle financier volumineux, de gérer des macros VBA, ou de faire coopérer plusieurs utilisateurs sur le même classeur en temps réel, l'approche MCP ajoute une couche d'interprétation par le modèle qui n'apporte rien. Le README ne mentionne ni verrouillage de fichier, ni gestion de concurrence, ni recalcul de formules. En mode HTTP, la contrainte de chemin relatif signifie aussi qu'un agent ne peut pas atteindre un fichier hors de EXCEL_FILES_PATH, ce qui est une protection mais peut bloquer un flux de travail existant. Enfin, la validation annoncée porte sur les plages et les formules, pas sur le sens métier de ce que l'agent écrit : un outil qui accepte une formule arbitraire peut produire un classeur syntaxiquement valide et sémantiquement faux. Le README ne décrit aucun garde-fou à ce niveau.

Alternatives : écrire le code soi-même

L'alternative la plus directe n'est pas un autre serveur MCP, c'est openpyxl, la bibliothèque Python que ce type de projet utilise presque toujours en dessous. La différence d'approche est nette : avec openpyxl, vous écrivez le script, vous contrôlez chaque appel, et le résultat est déterministe. Avec excel-mcp-server, c'est le modèle qui choisit la séquence d'outils, ce qui permet à un agent de réagir à une demande en langage naturel, mais introduit une variabilité dans l'exécution. Le choix dépend donc de qui décide : un pipeline planifié penche vers openpyxl, un agent qui doit improviser un rapport penche vers le serveur MCP. Le README ne compare pas les deux et ne revendique aucune supériorité de performance. À noter également que le projet propose un hébergement sur Smithery, ce qui déplace la question de l'exploitation vers un tiers.

Maintenance, licence et ce qu'il reste à vérifier

La licence est MIT, ce qui autorise l'usage commercial et la modification, à condition de conserver l'avis de licence et la clause de non-garantie. Le projet n'est pas archivé et la dernière version publiée est v0.1.8, datée du 12 avril 2026, après v0.1.7 en août 2025 et v0.1.6 en août 2025 : deux versions rapprochées à l'été 2025, puis un silence de plusieurs mois avant la 0.1.8. Le numéro de version reste en 0.1.x, ce qui, sans préjuger de la stabilité réelle, signale que l'API des outils peut encore bouger. Aucune politique de compatibilité n'est mentionnée dans le README. Le fichier TOOLS.md, référencé mais absent du matériel fourni, est la première chose à lire avant de s'engager : c'est lui qui déterminera si les outils correspondent à votre cas d'usage et si leurs paramètres sont stables. Le README ne documente ni procédure de mise à jour, ni matrice de compatibilité Python, ni canal de support.

Conclusion éditoriale

Adoptez excel-mcp-server si votre agent doit écrire dans des classeurs Excel sans qu'Excel soit installé sur la machine, et si vous acceptez de définir EXCEL_FILES_PATH côté serveur pour les transports HTTP. Évitez-le pour du calcul lourd sur de gros volumes, pour du multi-utilisateur concurrent, ou si vous ne pouvez pas auditer le contenu de TOOLS.md avant de donner à un agent le droit d'écrire dans vos fichiers. Avant tout déploiement, lancez `uvx excel-mcp-server stdio`, vérifiez que l'agent liste bien les outils, puis testez la création d'un fichier dans un répertoire jetable pour observer où le fichier atterrit réellement.

Sources officielles

1. haris-musa/excel-mcp-server on GitHub
2. License: MIT
3. Project website
4. README
5. Releases