MCP : quand votre assistant IA apprend à voir, créer et agir

Tout a commencé avec un bol de dal

Dimanche dernier, je construisais une appli de menu de cantine pour mes enfants. Rien de sérieux — un petit projet du week-end, le genre de truc qu’on fait entre deux cafés. Le menu affichait “Dal indien avec riz” et je voulais une belle image pour l’accompagner. Réflexe naturel : je demande à Claude. “Génère-moi une image de dal indien avec du riz basmati, style photo culinaire.”

Claude me répond poliment qu’il ne peut pas faire ça.

Évidemment. Claude est un modèle de langage. Il manipule du texte, pas des pixels. Alors j’ai fait ce qu’on fait tous : j’ai quitté mon éditeur, ouvert un navigateur, cherché un générateur d’images, retapé mon prompt, attendu, téléchargé le résultat, déplacé le fichier dans le bon dossier. Cinq minutes pour une image. Cinq minutes de friction pure, de contexte perdu, de flow interrompu.

Et c’est là que ça m’a frappé. Pas le problème de l’image — le problème de l’architecture. Nos assistants IA sont des cerveaux sans corps. Ils peuvent réfléchir, analyser, rédiger avec une précision remarquable. Mais ils ne peuvent pas agir. Pas d’yeux pour voir une image, pas de mains pour appeler une API, pas de jambes pour aller chercher une donnée dans un système externe.

Cette image ? Générée 1,5 seconde plus tard, directement dans le chat, pour 0,005$. Une fois le serveur MCP en place.

Le protocole qui donne des mains à l’IA

MCP — Model Context Protocol — est la réponse à ce problème. Créé par Anthropic en novembre 2024, c’est un standard ouvert qui définit comment un assistant IA peut appeler des outils externes. Pensez-y comme l’USB-C de l’IA : un connecteur universel qui permet de brancher n’importe quel outil sur n’importe quel assistant.

Avant MCP, si vous vouliez que votre IA interroge Salesforce, il fallait un développement custom. Qu’elle génère des images ? Autre développement. Qu’elle pilote votre CI/CD ? Encore un autre. Chaque intégration était un silo, fragile, coûteux à maintenir, impossible à réutiliser.

Avec MCP, vous écrivez un serveur une fois. Il expose des outils standardisés. Et n’importe quel client compatible — Claude Desktop, Kiro, Cursor, VS Code — peut les utiliser immédiatement. L’écosystème compte déjà des centaines de serveurs : bases de données, CRM, e-commerce, DevOps, productivité. Un assistant IA avec MCP ne se contente plus de répondre à vos questions. Il exécute vos demandes.

Pruna AI : la startup franco-allemande que personne ne connaît (et c’est dommage)

Revenons à mon problème d’image. J’avais besoin d’une API de génération rapide, pas chère, avec une vraie API REST — pas un bot Discord comme Midjourney, pas un truc à 0,08$ l’image comme DALL-E 3.

J’ai découvert Pruna AI un peu par hasard. C’est une boîte franco-allemande, fondée par des chercheurs en machine learning issus de la TU Munich et de l’écosystème parisien. Deux hubs de recherche — Munich et Paris — plus de 300 publications scientifiques, et 9 000 modèles open source optimisés à leur actif. Leur slogan officieux : “Built with Pretzels & Croissants”. Ça ne s’invente pas.

Le nom vient de “pruning” — l’élagage de réseaux de neurones. Leur approche est élégante : ils ne créent pas de modèles, ils prennent les meilleurs modèles open source (FLUX, SDXL, Stable Diffusion) et les optimisent via quantization et pruning pour qu’ils tournent plus vite sur moins de hardware. C’est de la recherche appliquée de haut niveau, pas du marketing. Le résultat concret : des images en 1,5 seconde pour un demi-centime. Pas une faute de frappe. 0,005$ par image.

Replicate a plus de modèles, mais Pruna est 2 à 10 fois moins cher et plus rapide sur les modèles qu’ils proposent. Et contrairement aux géants américains, c’est une équipe européenne, avec des données qui transitent par des infrastructures européennes. Pour un serveur MCP où la latence compte (l’utilisateur attend dans le chat), c’était le choix évident.

Construire le serveur avec Kiro : une session, pas un sprint

J’aurais pu coder ça à la main. Client HTTP, gestion d’erreurs, retry, validation, tests — comptez 2-3 jours pour un développeur expérimenté. Au lieu de ça, j’ai ouvert Kiro.

Kiro est un IDE agentique développé par AWS. Le principe : vous décrivez ce que vous voulez, Kiro génère les specs, vous validez, Kiro implémente, vous reviewez. Ce n’est pas du “vibe coding” où on laisse l’IA faire n’importe quoi et on espère que ça marche. C’est un workflow structuré où chaque décision d’architecture reste la vôtre, mais où vous ne tapez plus chaque caractère.

Pour le serveur Pruna, ça a donné ça : j’ai décrit les 6 outils que je voulais exposer (génération, édition, upscale, vidéo, catalogue, upload). J’ai précisé les contraintes — fallback async pour la vidéo, gestion transparente des fichiers locaux, images inline dans le chat. Kiro a proposé une architecture en 5 modules. J’ai ajusté deux trucs (le client HTTP séparé pour les uploads multipart, la validation fail-fast de la config). Et en une session, j’avais 400 lignes de code propre, 100 tests, 93% de couverture, prêt à publier sur PyPI.

Le truc qui m’a le plus surpris : la qualité du code de gestion d’erreurs. Retry exponentiel avec jitter, timeouts configurables, messages d’erreur qui disent exactement ce qui a merdé et comment le corriger. Le genre de code qu’on écrit bien quand on a le temps — et qu’on bâcle quand on est pressé. Kiro ne bâcle pas.

Les 6 outils en détail

generate_image  → texte vers image, 10 modèles (~1,5s, 0,005$)
edit_image      → modifier une image avec des instructions texte (~2s, 0,01$)
upscale_image   → amélioration IA jusqu'à 8 mégapixels (~4,5s, 0,005$)
generate_video  → texte ou image vers vidéo (~43s, 0,02-0,04$/s)
list_models     → parcourir le catalogue avec prix et capacités (gratuit)
upload_file     → envoyer un fichier local pour l'édition (gratuit)

Le design qui fait la différence au quotidien : quand vous dites “édite cette image” en pointant vers un fichier sur votre disque, le serveur détecte que c’est un chemin local, l’upload automatiquement vers Pruna, lance l’édition, et vous renvoie le résultat inline. Vous ne voyez jamais l’upload. Vous ne savez même pas qu’il a eu lieu. C’est ça, la bonne abstraction.

Pour la vidéo, même logique : la génération prend ~45 secondes. Trop long pour un appel synchrone. Le serveur essaie d’abord en sync, et si le timeout est dépassé, il bascule en async avec polling. L’utilisateur attend un peu plus longtemps, mais il n’a rien à faire de différent.

Ce que j’ai appris sur l’écosystème MCP (à la dure)

L’écosystème a 6 mois. C’est jeune. Et ça se sent dans les coins.

Claude Desktop lance les serveurs MCP avec PATH=/usr/bin:/bin. C’est tout. Si votre serveur a besoin de uv ou de n’importe quel outil installé dans votre home, il ne le trouvera pas. Pas d’erreur. Pas de log. Le serveur ne démarre simplement pas, et Claude vous dit “aucun outil disponible” sans plus d’explication. J’ai perdu 20 minutes là-dessus avant de comprendre. La solution : chemin absolu dans la config. /Users/vous/.local/bin/uvx, pas uvx.

Kiro demande une triple déclaration pour chaque outil. Le serveur dans mcpServers, les outils dans tools, et encore les outils dans allowedTools. C’est verbeux mais c’est un choix de sécurité — rien ne s’exécute sans autorisation explicite. Le piège : oubliez une des trois entrées et tout échoue silencieusement. Testez toujours avec --log-level debug.

Le helper Image() de FastMCP est un piège. Il marche parfaitement quand vous retournez une seule image. Mais dès que vous voulez retourner du texte ET une image (ce qui est le cas 100% du temps — “Voici votre image, générée avec le modèle X en 1,4s”), ça crash. La solution : oubliez les helpers, utilisez directement ImageContent et TextContent du SDK MCP.

Et maintenant ?

Le serveur est publié, il fonctionne, il est utilisé. Mais ce qui m’intéresse, c’est ce que ça représente pour la suite.

MCP est en train de faire aux assistants IA ce que les APIs REST ont fait au web il y a 20 ans : transformer des systèmes isolés en un écosystème connecté. Aujourd’hui, il existe des serveurs MCP pour PostgreSQL, Shopify, GitHub, Slack, Google Drive, AWS. Chaque semaine, de nouveaux apparaissent. Dans 12 mois, un assistant IA sans accès MCP sera aussi limité qu’un smartphone sans connexion internet.

Et le développement agentique avec Kiro rend la construction de ces serveurs accessible à n’importe quel développeur. Pas besoin d’être expert en protocoles réseau ou en sérialisation binaire. Vous décrivez ce que vous voulez, vous validez l’architecture, vous reviewez le code. Une session suffit.

Si vous avez une API métier — votre ERP, votre CRM, votre outil de gestion interne — vous pouvez la rendre accessible à vos équipes via leur assistant IA. En un après-midi. C’est exactement le genre de projet qu’on accompagne chez LCMH. Parlons-en.

🚀 Installer pruna-mcp-server

En une commande, votre assistant IA génère des images :

uvx pruna-mcp-server

Ou si vous préférez pip :

pip install pruna-mcp-server

Ensuite :

1. Créez votre clé API sur le portail développeur Pruna
2. Ajoutez le serveur à votre client MCP (guide de configuration)
3. Tapez “génère-moi une image de…” dans votre chat

Liens :

• 📦 GitHub — code source, issues, contributions
• 🐍 PyPI — pip install pruna-mcp-server
• 🔌 MCP Registry — io.github.charlesrapp/pruna
• 🌐 Pruna AI — le service derrière l’API