MCP RTK : réduire 90% des tokens MCP

J’utilise Claude Code au quotidien pour développer. Comme beaucoup de développeurs, j’ai connecté plusieurs serveurs MCP (GitLab, Grafana, Sentry…) pour donner à Claude un accès direct à mes outils. Le problème : chaque appel MCP injecte des dizaines de milliers de tokens dans le contexte, et la facture explose.

J’ai construit MCP RTK pour résoudre ce problème. C’est un proxy MCP écrit en Rust qui s’intercale entre Claude Code et les serveurs MCP pour filtrer les réponses avant qu’elles n’atteignent le modèle. Résultat : plus de 267 millions de tokens économisés sur mes 38 000+ commandes.

Le problème : des réponses MCP surdimensionnées

Le protocole MCP (Model Context Protocol) permet à Claude d’interagir avec des outils externes. Quand Claude appelle un outil MCP, le serveur renvoie une réponse JSON. Le souci, c’est que ces réponses contiennent souvent :

• des champs vides ou null qui n’apportent rien
• des métadonnées techniques (timestamps internes, IDs de pagination, headers HTTP)
• des valeurs très longues (logs complets, descriptions HTML, diffs entiers)
• des tableaux avec des dizaines d’entrées quand 5 suffiraient

Un seul appel list_issues sur GitLab peut consommer plus de 180 000 tokens. Claude n’a besoin que d’une fraction pour répondre à la question. Le reste est du gaspillage pur.

Sur une session de travail typique avec 50 à 100 appels MCP, ça représente facilement 500 000 tokens inutiles injectés dans le contexte.

La solution : un proxy de filtrage en 8 étapes

MCP RTK s’intercale de manière transparente entre Claude Code et les serveurs MCP. Aucune modification du workflow : Claude continue d’appeler les mêmes outils, mais les réponses passent par un pipeline de filtrage avant d’être injectées dans le contexte.

Le pipeline comprend 8 étapes :

1. Suppression des champs null et vides - les champs sans valeur sont retirés
2. Troncature des chaînes longues - les valeurs qui dépassent un seuil configurable sont coupées
3. Whitelist de champs - seuls les champs utiles sont conservés
4. Blacklist de champs - les champs connus comme inutiles sont retirés
5. Déduplication - les entrées identiques sont fusionnées
6. Compression des tableaux - les tableaux longs sont échantillonnés
7. Suppression des métadonnées techniques - les champs internes des APIs sont retirés
8. Normalisation - le format de sortie est standardisé

Chaque étape est configurable indépendamment. On peut activer ou désactiver chaque filtre, ajuster les seuils, et définir des règles spécifiques par serveur MCP.

Configuration par presets

La configuration se fait via un fichier TOML. MCP RTK propose des presets communautaires préconfigurés pour les serveurs populaires :

[servers.gitlab]
preset = "gitlab"

[servers.grafana]
preset = "grafana"

[servers.sentry]
preset = "sentry"

Chaque preset définit les champs à conserver, ceux à exclure, et les seuils de troncature adaptés au serveur. Pour un serveur custom, on définit les règles directement :

[servers.my-api]
whitelist = ["id", "name", "status", "created_at"]
max_string_length = 500
max_array_length = 10

MCP RTK détecte automatiquement les serveurs MCP installés et propose de les configurer.

Résultats

Sur mes 38 000+ commandes, MCP RTK a économisé 267 millions de tokens avec un taux de réduction moyen de 87%. Sur Opus 4.6 ($15/M tokens en input), ça représente environ 4 000 $ d’économies :

L’information utile est préservée. Claude répond avec la même précision, mais consomme beaucoup moins de tokens par session. La commande mcp-rtk gain permet de suivre les économies en temps réel :

Tokens saved:      267.1M (86.7%)
Efficiency meter: █████████████████████░░░ 86.7%

Installation

MCP RTK est distribué comme un binaire unique :

cargo install mcp-rtk

Une seule ligne à changer dans votre configuration Claude Code - on wrappe la commande MCP existante avec mcp-rtk -- :

{
  "mcpServers": {
    "gitlab": {
      "command": "mcp-rtk",
      "args": ["--", "npx", "-y", "@nicepkg/gitlab-mcp"],
      "env": { "GITLAB_PERSONAL_ACCESS_TOKEN": "glpat-..." }
    }
  }
}

MCP RTK détecte le serveur upstream depuis la commande et charge automatiquement le preset correspondant.

Pourquoi Rust ?

Le choix de Rust n’est pas anodin. Le proxy doit traiter chaque réponse MCP avec une latence minimale pour ne pas ralentir le workflow. Rust offre :

• un temps de démarrage quasi instantané (pas de JVM, pas de runtime)
• une empreinte mémoire minimale (quelques Mo)
• un binaire unique sans dépendances à installer
• des garanties de sécurité mémoire à la compilation

Le code est open source

MCP RTK est publié sous licence MIT sur GitLab (miroir GitHub). Les presets communautaires sont maintenus par la communauté : chaque utilisateur peut contribuer ses propres configurations pour de nouveaux serveurs MCP.

Le projet fait partie d’un écosystème d’outils que je développe autour de Claude Code, avec Skill Radar (détection de patterns répétitifs dans les sessions) et Claude Deck (multi-workspace pour sessions parallèles). Pour apprendre à écrire vos propres skills, voir le guide sur les skills efficaces. Le même principe “charger moins” s’applique aux skills eux-mêmes : au-delà de ~30 skills, en ajouter dégrade l’agent. La page du projet contient les liens d’installation et la documentation.

Le choix et la configuration des serveurs MCP, et la maîtrise de leur coût en tokens, sont au programme de ma formation Claude Code.