arxiv-mcp-server : lire le LaTeX source d'un papier arXiv section par section

Le problème : un agent qui cite sans avoir lu

Un agent qui résume un papier à partir de son abstract produit une sortie plausible et souvent fausse sur le détail. Le README du projet pose le diagnostic en creux : la boucle de travail revendiquée est « paper ID → outline → one section → citations ». Autrement dit, l'agent part d'un identifiant arXiv, obtient un plan, lit une section à la fois, puis produit des citations. Le public visé est donc l'ingénieur ou le chercheur qui fait tourner un agent de littérature dans Claude Code, Codex, Cursor, VS Code, Kiro ou Claude Desktop, et qui veut que les affirmations sur un papier s'appuient sur le texte soumis par les auteurs, pas sur une reformulation. Le serveur ne cherche pas à remplacer un moteur de recherche scientifique. Il se présente comme un serveur MCP local dont le différenciateur tient en trois éléments : lecture du LaTeX source par section, BibTeX dérivé des métadonnées arXiv, et veilles par sujet conservées sur disque.

Ce qui reste sur la machine et ce qui sort

La séparation annoncée est nette. Selon le README, la recherche, la récupération des sources, les graphes de citations et les téléchargements appellent leurs services externes respectifs. Ce qui reste local, c'est la boucle de littérature : lire le LaTeX un morceau à la fois, exporter le BibTeX, tenir des veilles par sujet. Le serveur tourne en local sur stdio par défaut. Cette architecture a une conséquence pratique : la qualité de la sortie dépend de ce que l'archive arXiv expose réellement. Tout papier déposé en PDF seul, sans source LaTeX, sort du chemin principal. Le README ne décrit pas de mécanisme de repli pour ces cas, et c'est une limite de conception à connaître avant de bâtir un flux de travail dessus. Le choix de garder les papiers sur disque a un autre effet : le répertoire de stockage devient un état que l'agent lit et écrit, donc quelque chose à sauvegarder, à inspecter et à purger.

Installation : une seule commande, plusieurs clients

L'installation par défaut tient en une ligne : uvx arxiv-mcp-server. Elle suppose uv, qui fournit uvx, et rien d'autre : pas de clone du dépôt, pas d'environnement Python à préparer. Pour les clients qui acceptent la forme JSON mcpServers, la configuration donnée dans le README est la suivante : une entrée arxiv, de type stdio, avec command uvx et args ["arxiv-mcp-server"]. Le README précise que d'autres clients attendent un objet servers de premier niveau, du TOML, ou leur propre interface de réglages.

Le répertoire par défaut des papiers est ~/.arxiv-mcp-server/papers. Pour en choisir un autre, il faut ajouter "--storage-path", "/absolute/path/to/papers" à la fin de args. Le chemin doit être absolu, et c'est le seul paramètre de configuration mis en avant dans le matériel fourni.

Les recettes par client sont explicites. Claude Code : claude mcp add --transport stdio --scope user arxiv -- uvx arxiv-mcp-server, avec vérification via claude mcp get arxiv. Codex : codex mcp add arxiv -- uvx arxiv-mcp-server, puis codex mcp get arxiv. Hermes : hermes mcp add arxiv --command uvx --args arxiv-mcp-server, puis hermes mcp test arxiv pour tester la connexion enregistrée. Kiro accepte la configuration générique dans .kiro/settings/mcp.json pour un espace de travail, ou ~/.kiro/settings/mcp.json pour tous. Un piège est signalé sans ambiguïté : un paquet npm sans rapport porte le même nom, donc il ne faut pas installer ce serveur avec npm, pnpm ou npx.

Deux modes d'intégration qui ne coûtent pas la même chose

Le projet propose, pour Claude Code et Codex, une installation directe du serveur MCP et une installation par plugin qui ajoute une compétence de recherche arXiv. Côté Claude Code, la variante plugin passe par claude plugin marketplace add blazickjp/arxiv-mcp-server puis claude plugin install arxiv-mcp-server@arxiv-mcp. Côté Codex, par codex plugin marketplace add blazickjp/arxiv-mcp-server puis codex plugin add arxiv-mcp-server@arxiv-mcp. Kiro dispose d'un équivalent sous forme de Power importé depuis l'URL GitHub du dépôt, qui lit mcp.json et ajoute des consignes de recherche.

La différence n'est pas cosmétique. La connexion MCP seule expose des outils que l'agent décide d'appeler. Le plugin ajoute des instructions qui orientent cette décision. Si vous voulez maîtriser ce que l'agent fait, la connexion directe est plus lisible : vous voyez les outils, vous voyez les appels. Si vous constatez que l'agent n'utilise jamais la lecture section par section et se rabat sur des résumés, la compétence embarquée est le levier prévu par les auteurs. Notez aussi qu'après l'installation du plugin Claude Code, il faut redémarrer le client ou lancer /reload-plugins, et que la documentation ne décrit pas de procédure de mise à jour ou de désinstallation des plugins dans le matériel fourni.

Le coût de maintenance se lit dans le rythme des versions

Trois versions en quatre jours : v0.7.0 le 22 août 2026, v0.7.1 le 23, v0.7.2 le 24. Le dernier push sur main date du 26 août 2026. Ce rythme indique un projet en phase active de correction, ce qui a deux implications opposées. D'un côté, les défauts d'intégration avec les clients MCP se corrigent vite. De l'autre, épingler une version n'est pas un réflexe superflu : le README lui-même recommande le paquet arxiv-mcp-server==0.7.2, avec le numéro de version accolé au nom. Un agent qui appelle uvx arxiv-mcp-server sans épinglage récupère la dernière publication, ce qui peut changer le comportement des outils entre deux sessions sans que rien ne le signale.

Le projet est sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de licence et d'état des modifications. Le matériel fourni ne mentionne ni CLA, ni politique de gouvernance, ni engagement de support. Pour un usage interne en entreprise, cela suffit généralement ; pour redistribuer une version modifiée, faites relire les clauses par qui de droit, ce n'est pas un avis juridique.

Quand ce n'est pas le bon outil

Le cas d'échec le plus direct est le papier sans source LaTeX. La promesse centrale du serveur est la lecture du LaTeX soumis par les auteurs ; si l'archive ne propose que le PDF, il n'y a rien à lire section par section. Le README ne documente pas de conversion PDF ni de repli, donc un agent qui s'appuie sur ce serveur pour une revue de littérature couvrant des papiers plus anciens ou déposés sans source se retrouvera avec des trous silencieux.

Deuxième cas : vous cherchez un moteur de recherche. Le README le dit lui-même, « Search is optional », et la recherche passe par des services externes. Si votre besoin est de balayer un corpus par mots-clés, ce serveur n'est pas le bon point d'entrée.

Troisième cas : vous voulez un service partagé par une équipe. Le transport par défaut est stdio, le serveur tourne en local, et les papiers vont dans un répertoire utilisateur. Rien dans le matériel fourni ne décrit un mode serveur distant, une authentification ou un stockage partagé. Pour un usage multi-utilisateur, il faudra construire cette couche vous-même, et ce n'est pas ce que le projet cherche à résoudre.

Face à un client HTTP générique sur l'API arXiv

L'alternative la plus évidente n'est pas un autre serveur MCP, c'est un client HTTP écrit à la main contre l'API arXiv, greffé sur l'agent comme un outil maison. La différence d'approche est réelle. Un client maison vous laisse choisir le format de sortie, la gestion du cache, la politique de nouvelle tentative et le découpage du texte. En échange, vous implémentez vous-même le plan par sections, l'extraction BibTeX depuis les métadonnées, la persistance des veilles et l'exposition du tout au format d'outils attendu par le client MCP. Ce serveur arrive avec ces quatre briques déjà câblées et une configuration qui tient dans un objet JSON de cinq lignes.

L'arbitrage se joue donc sur le volume de code que vous ne voulez pas écrire, pas sur une supériorité technique. Si votre besoin se limite à télécharger un PDF et à en extraire le texte, un script de quelques dizaines de lignes suffit et vous évite une dépendance à un projet qui publie trois versions par semaine. Si votre besoin est la lecture structurée d'un papier avec citations vérifiables, la boucle fournie est plus courte à mettre en place que sa réimplémentation.

Conclusion éditoriale

À adopter si votre agent doit citer des papiers arXiv avec un BibTeX issu des métadonnées de l'archive, et si vous acceptez que la boucle de lecture reste locale. À éviter si votre besoin premier est la recherche plein texte : la recherche est explicitement optionnelle ici et passe par des services externes. Avant de déployer, vérifiez trois choses concrètes : la valeur de --storage-path si ~/.arxiv-mcp-server/papers ne convient pas, la présence de uvx sur la machine qui exécute le client MCP, et le nom exact du paquet, arxiv-mcp-server==0.7.2 sur PyPI, parce qu'un paquet npm homonyme ne correspond pas à ce serveur.

Sources officielles

1. blazickjp/arxiv-mcp-server on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases