Saturday, July 4, 2026

Mon dernier article montrait que 83% du coût d'un agent, c'est du contexte relu. Alors j'ai construit l'outil qui arrête de relire.

Blog post cover image
Il y a deux semaines, j'ai laissé une flotte d'agents Claude développer un repo à ma place. Résultat technique bluffant, et un constat qui m'a marqué : sur 5 milliards de tokens consommés, ~83% du coût n'était pas du code généré. C'était du contexte relu en boucle. À chaque turn, chaque agent relit l'intégralité de ce qu'il a sous les yeux.
Le pire, dans un repo C# : l'agent ouvre un fichier de 1 000 lignes pour en tirer une seule signature de méthode. Il relit le mur à chaque fois.
Alors j'ai construit l'outil qui règle ça. Il s'appelle RoselineMCP.

▸ L'idée : naviguer par structure, pas par texte

RoselineMCP est un serveur MCP en .NET qui donne à Claude, Cursor ou Copilot une vue Roslyn de ta solution C# : symboles, références, graphes d'appel, éditions chirurgicales.
Au lieu de relire le fichier source, l'agent demande la structure. Un seul appel search_symbols renvoie la forme d'un fichier, pas son contenu.
Exemple réel, tiré du repo lui-même :
L'agent récupère les signatures et les emplacements, pas les corps de méthode, pas les using, pas le mur. Exactement ce dont il a besoin pour naviguer, et rien de plus.

▸ Pas un parser. Le compilateur.

La différence clé avec un grep ou un tree-sitter : RoselineMCP est bâti sur Roslyn, la plateforme de compilation .NET, le moteur même qui compile ton code dans Visual Studio et le SDK.
Concrètement :
C'est une couche fine et honnête posée sur une fondation que tu utilises déjà tous les jours.

▸ 85% de tokens en moins, mesuré, pas marketé

Je déteste les chiffres sortis d'un chapeau. Alors le benchmark tourne sur la propre source de RoselineMCP (dogfooding), balaie systématiquement 293 symboles sur 54 fichiers, et tokenise chaque sortie réelle de l'outil avec un vrai tokenizer BPE.
Détail par outil (médiane vs. lecture du fichier entier) :
Et, c'est important, je montre aussi les cas faibles, pas seulement les beaux chiffres.
L'outline de fichier, par exemple, gagne gros sur les fichiers denses en code (Program.cs +89%) mais atteint tout juste l'équilibre sur un fichier qui n'est que des déclarations. Une interface EST déjà juste des signatures. La règle honnête : lis directement les petits, outline les gros.
De même, get_symbol_info avec le corps de la méthode inclus ne tombe qu'à ~66%, parce que tu récupères le code que tu vas éditer. L'outil ne prétend pas remplacer la lecture du code que tu t'apprêtes à modifier en profondeur. Il économise sur la navigation et l'orientation, là où va vraiment le gaspillage.

▸ Treize outils, de la structure en entrée, des tokens en moins en sortie

Neuf outils de code-intelligence par-dessus la surface de diagnostics d'origine :
Navigation (lecture seule) : search_symbols, get_symbol_info, find_references, find_implementations, get_call_graph, get_type_hierarchy, get_symbol_at_position.
Édition (diff au niveau du membre, aperçu par défaut) : edit_member remplace un seul membre et renvoie un diff unifié plutôt que de réécrire le fichier entier ; rename_symbol renomme et met à jour toutes les références via Roslyn.
Diagnostics et correctifs : analyze_solution, list_diagnostics, apply_fixes, create_patch.
Le point commun : tu émets un diff, pas une réécriture. Sur le rename, ça fait ~81% de tokens de sortie en moins.

▸ Pourquoi ça compte (et pas que pour l'économie)

Dans mon article précédent, ma conclusion était : l'avenir du dev autonome, ce ne sera pas « le meilleur modèle en boucle », mais « le bon modèle, au bon turn, avec le contexte minimal ».
RoselineMCP, c'est la partie « contexte minimal » rendue concrète pour l'écosystème .NET. Moins de contexte relu par turn, ça veut dire :
Ce n'est pas magique et je ne le vends pas comme tel. Sur certaines tâches, un grep bien ciblé fait jeu égal en tokens bruts. L'avantage de RoselineMCP là-dessus, c'est la structure et la précision (symboles résolus, références cross-projet, vrais liens d'appel), pas juste le compteur.

▸ Installation : une ligne, n'importe quel client MCP

RoselineMCP tourne comme un process stdio local que ton client MCP lance. La méthode recommandée (dnx, le « npx » de .NET) l'exécute à la demande, sans étape d'installation. Il faut juste le SDK .NET 10 :
{
  "mcpServers": {
    "roseline": {
      "command": "dnx",
      "args": ["RoselineMCP", "--yes"]
    }
  }
}
Vérifié avec Claude Desktop, VS Code (Copilot / MCP) et Cursor. Aussi disponible en outil global NuGet et en image Docker, et référencé dans le MCP Registry officiel.

▸ La suite

Je continue de creuser la même obsession qu'avec Koine : réduire le contexte transmis à chaque turn. RoselineMCP en est la brique .NET. Le benchmark est reproductible, tu peux le lancer sur ta propre solution et sortir TES chiffres (dotnet run --project RoselineMCP.TokenBenchmark).
Si tu bosses en C# avec un agent, je suis vraiment preneur de tes retours : sur quelles tâches tu vois le plus de gaspillage de contexte ? Et est-ce que tu mesures, ou tu ressens juste la facture monter ?
C'est open source (licence MIT) : github.com/Atypical-Consulting/RoselineMCP.