Aller au contenu
ReviewRamble

La lettre hebdomadaire

L’IA, évaluée, dans votre boîte mail.

  • Les nouveaux tests d’outils, de modèles, de serveurs MCP et de dépôts, avec le verdict en premier
  • Les prix et les notes revérifiés quand quelque chose change
  • Les nouvelles analyses dès leur publication

Modèles, agents, serveurs MCP et les outils qui méritent vraiment votre temps.

Un e-mail par semaine. Désinscrivez-vous avec le lien présent dans chaque lettre. Comment nous utilisons votre e-mail

agent-lsp

Met vos serveurs de langage existants au service d'un agent : références, diagnostics, aperçu des renommages et modifications vérifiées avant écriture.

Avis de ReviewRamble editors · Mis à jour

Notre note

3.9/5

Une passerelle complète entre serveurs de langage et agents, qui vérifie les modifications avant de les écrire, freinée par une liste d'outils démesurée et une jeunesse qui se lit dans son rythme de versions.

Qu’est-ce que agent-lsp ?

agent-lsp, de Blackwell Systems, est un serveur MCP qui lance et gère des serveurs de langage ordinaires comme gopls, rust-analyzer, pyright et clangd, et met ce qu'ils savent à la disposition d'un agent d'IA. Ses 66 outils couvrent l'accès à la définition, les références, les hiérarchies d'appels et de types, les diagnostics, les renommages et les actions de code, plus des appels composés comme blast_radius, qui renvoie en une étape les appelants d'un symbole, et une série d'outils de simulation qui appliquent une modification en mémoire et indiquent l'évolution des erreurs avant toute écriture.

C'est un binaire Go unique sous licence MIT, lancé en avril 2026, qui comptait environ 179 étoiles GitHub et neuf contributeurs lors de notre vérification. Les versions sont fréquentes : la v0.24.2 est sortie le 4 novembre 2026, troisième version de la journée. Le README liste 32 langages testés en CI contre de vrais serveurs de langage, et le paquet npm a été téléchargé 484 fois dans la semaine jusqu'au 12 novembre 2026.

Installer agent-lsp

npm install -g @blackwell-systems/agent-lsp && agent-lsp init

agent-lsp vaut-il le coup ?

agent-lsp s'attaque à une vraie faiblesse des agents de programmation : ils cherchent les appelants et renomment les symboles avec grep, et grep ne sait pas que deux fonctions portent le même nom. Un serveur de langage le sait, et agent-lsp en garde un actif par langage et laisse l'agent l'interroger directement. La mesure de l'auteur sur HashiCorp Consul, environ 319 000 lignes, a trouvé qu'une analyse d'impact demandait 119 appels d'outils et 841 Ko via le serveur de langage, contre 5 534 appels et 17,7 Mo avec grep et la lecture de fichiers.

Ce qui le distingue, c'est la vérification des modifications avant écriture. preview_edit et simulate_chain appliquent les changements en mémoire et indiquent quelle étape introduit de nouvelles erreurs, et safe_apply_edit n'écrit que si le nombre d'erreurs n'augmente pas, en refusant si l'aperçu a expiré ou si le serveur indexait encore. Des skills comme /lsp-refactor enchaînent analyse d'impact, aperçu, application, compilation et tests, et pour quatre d'entre elles le serveur bloque les appels faits dans le désordre. Serena, le rival le plus connu, modifie aussi par symbole ; l'aperçu en mémoire est ce qu'ajoute agent-lsp.

Sachez ce qu'il peut exécuter. run_build et run_tests lancent les commandes de votre propre projet, comme go build, cargo test, pytest ou npm test : un script de test ou un hook de compilation d'un dépôt douteux s'exécute donc avec vos droits d'utilisateur. execute_command transmet des commandes du serveur de langage, et les outils d'édition écrivent des fichiers source. Le transport par défaut est stdio ; un mode HTTP avec jeton bearer écoute sur 127.0.0.1 sauf choix contraire, et le README déconseille de passer le jeton en ligne de commande.

Le hic : 66 définitions d'outils pèsent lourd pour tout client qui les charge toutes, et les comparaisons du README, y compris l'idée qu'aucune autre passerelle MCP-LSP ne teste ses langages en CI, sont des affirmations du mainteneur. Les réponses sont par défaut au format GCF, le format compact de l'auteur, plutôt qu'en JSON, ce qui économise de 30 à 84 % des tokens selon ses chiffres, mais ajoute un format que vos propres outils ne sauront peut-être pas lire. Les projets Python et TypeScript ont toujours besoin d'un démon d'indexation en arrière-plan avant que les références soient fiables.

Notre avis : dans un dépôt polyglotte ou très gros où l'agent casse sans cesse des appelants, agent-lsp mérite un après-midi d'essai ; pour un petit projet en un seul langage, la recherche intégrée de l'agent suffit sans doute.

Là où il fait la différence

  • Un ingénieur plateforme qui maintient un monorepo Go de 300 000 lignes

    Renommer une fonction exportée et mettre à jour tous les appelants sans casser la compilation

    La skill /lsp-rename lance prepare_rename, montre chaque occurrence et applique le changement en une fois ; /lsp-verify lance ensuite go build et les tests. C'est gratuit ; le gain, ce sont les tours de CI ratés qu'un agent armé de grep a tendance à provoquer.

  • Une équipe full-stack de quatre personnes avec une API en Go et un front end en TypeScript

    Laisser une seule session d'agent parcourir les deux moitiés du code

    agent-lsp init écrit une configuration qui envoie les fichiers .go à gopls et les .ts à typescript-language-server. Le README signale que TypeScript 7 n'inclut plus tsserver : installez pour l'instant TypeScript 6 en global.

  • Une responsable technique qui nettoie un service Python hérité avant une migration

    Trouver les exports que personne n'appelle et les supprimer sans risque

    /lsp-dead-code liste les symboles sans référence et safe_delete_symbol renvoie le nombre d'erreurs après chaque suppression. Travaillez sur une branche ; pyright doit d'abord avoir fini d'indexer dans son démon.

Avant de vous engager

Mise en route
Installez avec npm install -g @blackwell-systems/agent-lsp, Homebrew, pip, Scoop, winget ou un script curl, puis installez les serveurs de langage nécessaires et lancez agent-lsp doctor et agent-lsp init, qui écrit la configuration MCP et les règles d'agent de votre client. La première session indexe l'espace de travail, environ 10 secondes pour un projet typique selon le README.
Intégrations
Claude Code, Cursor, Windsurf, Gemini CLI, Codex, Cline, Continue et Pi en stdio ; tout client en Streamable HTTP. 66 outils, 24 skills également exposées comme prompts MCP, des images Docker par langage et une bibliothèque Go pour utiliser directement le client LSP.
Données et confidentialité
Tourne en local avec vos droits d'utilisateur et lit, modifie et compile les espaces de travail que vous lui indiquez ; le code lu par l'agent part chez votre fournisseur de modèle. Le README ne décrit aucune télémétrie. Le mode HTTP utilise un jeton bearer et écoute sur 127.0.0.1 par défaut ; les images Docker tournent avec un utilisateur non root.
Coût à grande échelle
Gratuit sous MIT. Le coût, c'est le contexte et le temps : 66 définitions d'outils par session dans les clients qui les chargent toutes, plus la mémoire de chaque serveur de langage actif sur un gros dépôt.
Limites
La précision dépend de chaque serveur de langage. Python et TypeScript demandent plusieurs minutes d'indexation au premier usage ; un démon en arrière-plan garde l'index chaud et s'arrête après 30 minutes d'inactivité. La refactorisation interactive exige gopls v0.24 ou plus récent.

Les points forts

  • S'appuie sur de vrais serveurs de langage, donc références et renommages tiennent compte des types
  • Les modifications se prévisualisent en mémoire avec le nombre d'erreurs avant et après
  • Un seul processus gère plusieurs langages dans la même session
  • Binaire unique, installable via npm, pip, Homebrew, Scoop et winget

Les points faibles

  • 66 outils pèsent sur le contexte des clients qui les chargent tous
  • run_tests et run_build exécutent les scripts du projet
  • Sortie par défaut au format GCF de l'auteur, pas en JSON
  • Projet jeune ; les comparaisons avec les rivaux sont déclaratives

Idéal pour

Les ingénieurs qui utilisent Claude Code, Codex ou Cursor sur des bases de code volumineuses ou multilingues et veulent des refactorisations vérifiées par un vrai serveur de langage.

Alternatives à agent-lsp

agent-lsp : questions fréquentes

agent-lsp vaut-il le coup ?
Une passerelle complète entre serveurs de langage et agents, qui vérifie les modifications avant de les écrire, freinée par une liste d'outils démesurée et une jeunesse qui se lit dans son rythme de versions. Nous lui donnons 3.9 sur 5.
Combien coûte agent-lsp ?
Gratuit et open source (MIT).
Quels sont les inconvénients de agent-lsp ?
66 outils pèsent sur le contexte des clients qui les chargent tous; run_tests et run_build exécutent les scripts du projet; sortie par défaut au format GCF de l'auteur, pas en JSON; projet jeune ; les comparaisons avec les rivaux sont déclaratives.
À qui s’adresse agent-lsp ?
Les ingénieurs qui utilisent Claude Code, Codex ou Cursor sur des bases de code volumineuses ou multilingues et veulent des refactorisations vérifiées par un vrai serveur de langage.
Combien coûte agent-lsp pour une équipe ou en production ?
Gratuit sous MIT. Le coût, c'est le contexte et le temps : 66 définitions d'outils par session dans les clients qui les chargent toutes, plus la mémoire de chaque serveur de langage actif sur un gros dépôt.
agent-lsp est-il sûr pour les données de l’entreprise ?
Tourne en local avec vos droits d'utilisateur et lit, modifie et compile les espaces de travail que vous lui indiquez ; le code lu par l'agent part chez votre fournisseur de modèle. Le README ne décrit aucune télémétrie. Le mode HTTP utilise un jeton bearer et écoute sur 127.0.0.1 par défaut ; les images Docker tournent avec un utilisateur non root.
Quelles sont les meilleures alternatives à agent-lsp ?
Les alternatives les plus proches que nous avons testées sont Serena et Lean LSP MCP.

Réponses vérifiées le 13 nov. 2026.