amphi-mcp : j'ai publié un serveur MCP pour mon SaaS, voici pourquoi

Ce que vous allez apprendre

• Pourquoi publier un serveur MCP pour un SaaS en 2026 a le même poids stratégique que publier une API REST en 2015

• L'architecture concrète d'amphi-mcp : SDK officiel, validation zod, trois tools, transport stdio

• Le choix de la distribution npm + GitHub et les arbitrages d'auth pour une V1

• La check-list pour faire pareil avec votre propre produit, étape par étape

J'ai publié amphi-mcp sur npm il y a deux jours. C'est un serveur MCP qui permet à n'importe quel agent (Claude, Cursor, Zed, Continue, Dust…) de créer une présentation Amphi à partir de HTML, de PDF ou d'images, en autonomie. La V1 fait 10,9 ko unpacked. Voici pourquoi je l'ai fait, ce qu'il y a dedans, et ce que j'en retiens pour quiconque édite un produit en 2026.

Si vous découvrez le protocole MCP, lisez d'abord MCP : ce que c'est et pourquoi ça change tout pour les agents IA. Pour le contexte du produit Amphi, voir Amphi : présentation live avec quiz et transcription IA.

Pourquoi publier un MCP pour son SaaS

La thèse est simple. En 2015, un SaaS sans API REST n'existait pas vraiment dans l'écosystème : pas d'intégration Zapier, pas de webhook, pas de plug-in tiers, donc invisible aux outils qui voulaient l'utiliser en chaîne. En 2026, un SaaS sans serveur MCP commence à avoir le même problème — invisible aux agents qui voudraient s'en servir en autonomie.

Concrètement : si un utilisateur dit à Claude « génère-moi un deck sur l'IA en PME et publie-le sur Amphi », un agent compatible MCP va chercher si Amphi expose un tool de publication. S'il en trouve un, il le déclenche. S'il n'en trouve pas, il propose à l'utilisateur d'aller le faire à la main — et là, dans neuf cas sur dix, l'utilisateur ouvre le concurrent qui a un MCP.

C'est exactement le mouvement qu'on voit côté serveurs MCP officiels en 2026 : Notion, Stripe, Supabase, Cloudflare, HubSpot, Make, et maintenant data.gouv.fr du côté public. La voie est tracée.

Ce qu'expose amphi-mcp

La V1 expose trois tools, choisis volontairement pour couvrir les trois sources de présentation les plus courantes :

• create_presentation_from_html — prend un fichier HTML autonome (typiquement celui produit par la skill amphi-html-deck) et le publie comme nouvelle présentation Amphi. Retourne l'URL de session.

• create_presentation_from_pdf — prend un PDF (chemin local ou base64) et le convertit en présentation Amphi. Couvre les cas où on part d'un export Keynote, Google Slides ou Canva existant.

• create_presentation_from_images — prend une liste d'images (PNG/JPEG) et les agence en slides séquentielles. Utile pour des supports de cours, des planches techniques ou des moodboards.

Trois tools, c'est volontairement peu. Le piège classique de la V1 d'un MCP est de vouloir tout exposer : créer, lister, modifier, supprimer, partager, configurer, dupliquer. On se retrouve avec quinze tools, dont seulement deux ou trois sont vraiment appelés, et un schéma JSON Schema lourd qui pollue la fenêtre de contexte de l'agent. Je préfère partir étroit et élargir en fonction des usages réels.

Architecture choisie

Quatre décisions techniques structurantes.

SDK officiel TypeScript. Le serveur utilise @modelcontextprotocol/sdk en version ^1.12. C'est le SDK maintenu par Anthropic, à jour avec la spec du protocole, et qui gère toute la sérialisation MCP de manière transparente. Pas la peine de réimplémenter le wire format.

Validation des inputs avec zod. Chaque tool déclare son schéma d'entrée avec zod. Le SDK utilise ces schémas pour générer le JSON Schema exposé aux agents, et pour valider les paramètres reçus avant exécution. C'est une bonne pratique évidente mais critique : un agent qui appelle un tool avec des paramètres mal formés doit échouer proprement avec un message lisible, pas faire planter le process.

Transport stdio. Pour la V1, le serveur tourne en stdio (local). L'utilisateur l'installe via npm install -g amphi-mcp, le déclare dans la config Claude Desktop, et l'agent lance le process à la demande. C'est plus simple à shipper qu'un serveur distant en HTTP/SSE qui demanderait OAuth, hébergement, monitoring. La version distante viendra plus tard, quand le besoin multi-utilisateurs sera concret.

Pas d'auth en V1. Choix assumé : le serveur ne demande pas de clé Amphi à l'utilisateur. Les présentations créées sont publiques (c'est le mode par défaut d'Amphi pour les sessions de formation live). Quand on ajoutera le mode privé / espace équipe, on introduira l'auth — probablement OAuth 2.1 comme la spec MCP le recommande désormais.

Distribution

Trois canaux activés :

1. npm — le package est publié sous le nom amphi-mcp, en license MIT, accessible via npm install -g amphi-mcp. Le binaire amphi-mcp est exposé et utilisable directement dans la config Claude Desktop.

2. GitHub — le code est ouvert, sous le repo github.com/Oliviercreativ/amphi-mcp. README détaillé, exemples de config, licence MIT. C'est aussi là que les retours et issues peuvent remonter.

3. Annuaires communautaires — référencement dans mcp.so et smithery.ai au fur et à mesure des releases. Les deux annuaires sont devenus en 2026 les points de découverte de référence pour les MCP communautaires.

Total : 10,9 kB unpacked, 2 dépendances (le SDK officiel + zod). C'est volontairement minimal — un MCP n'a pas besoin d'être un gros package pour faire son travail.

Si vous voulez faire pareil pour votre produit

La check-list courte, telle que je la conseillerais en 2026 :

1. Choisir trois tools maximum pour la V1. Les actions les plus appelées par vos utilisateurs sur votre interface actuelle — pas celles que vous trouvez « techniquement intéressantes ».

2. Partir du SDK officiel. En TypeScript via @modelcontextprotocol/sdk ou en Python via mcp. Ne pas réimplémenter le protocole à la main.

3. Valider tous les inputs. zod en TS, pydantic en Python. C'est la couche qui rend l'expérience agent prévisible.

4. Commencer en stdio. Plus simple, plus rapide à shipper, suffisant pour 90% des cas d'usage solo. La version distante viendra quand un besoin précis l'exigera.

5. Documenter les permissions. Même sans auth, expliquer ce que les tools peuvent faire et ce qu'ils ne peuvent pas — c'est ce que regarderont les utilisateurs avant d'installer.

6. Publier sur npm + GitHub + annuaires. Les trois sont gratuits, prennent peu de temps, et l'absence de l'un d'eux limite directement la visibilité.

7. Itérer sur les vrais usages. Les premiers retours montrent toujours des écarts entre ce qu'on pensait que les agents allaient appeler et ce qu'ils appellent vraiment. Ajuster les noms de tools, les descriptions, les schémas d'entrée en fonction.

Pour une équipe produit, c'est un chantier qui se fait en deux à cinq jours pour une V1, selon la complexité de l'API existante. Le coût d'opportunité de ne pas le faire grimpe vite.

Premiers retours

Trop tôt pour des chiffres significatifs (publié il y a deux jours), mais les premières utilisations confirment l'intuition : les agents appellent create_presentation_from_html dans la grande majorité des cas, parce que c'est le tool qui s'enchaîne naturellement avec la génération. create_presentation_from_pdf remonte pour les cas « j'ai un export existant ». create_presentation_from_images est moins utilisé pour l'instant — il faudra peut-être l'ajuster ou le marquer plus clairement dans la description.

Côté distribution, npm sert pour l'installation, mais c'est le README sur GitHub qui sert de page de référence : description claire des tools, exemple de config Claude Desktop, screenshots d'une session type.

Ce qu'il faut retenir

• Publier un MCP pour un SaaS en 2026 est l'équivalent stratégique de publier une API REST en 2015 : sans ça, vous devenez invisible aux agents IA

• Partir étroit (3 tools max pour la V1) et itérer sur les vrais usages plutôt que d'essayer d'exposer toute l'API d'un coup

• SDK officiel + validation zod + transport stdio : le combo le plus rapide pour shipper une V1 propre

• Distribution sur npm + GitHub + annuaires (mcp.so, smithery.ai) — les trois sont gratuits et indispensables

• Le couple skill + MCP — amphi-html-deck côté génération, amphi-mcp côté publication — boucle complètement la chaîne d'usage

Questions fréquentes

Combien de temps pour shipper une V1 de MCP ? Entre deux et cinq jours pour un produit dont l'API REST existe déjà, selon la complexité des tools choisis. Le gros du temps part dans l'écriture des schémas zod et la rédaction des descriptions de tools — pas dans le code MCP lui-même.

Faut-il auth ou pas pour une V1 ? Si votre produit est en mode « tout-public » ou « per-user local », vous pouvez shipper sans auth. Dès que vous touchez à du payant, à des données personnelles, ou à du SaaS multi-utilisateurs, OAuth 2.1 devient indispensable. La spec MCP a standardisé ça désormais.

Stdio ou HTTP/SSE : lequel choisir ? Stdio pour 90% des cas en V1 : plus simple, plus rapide à shipper, pas d'hébergement. HTTP/SSE devient nécessaire si vous voulez servir le MCP comme un produit cloud multi-utilisateurs, ou si l'installation locale est un frein pour votre cible.

Comment les utilisateurs découvrent un MCP ? Trois sources en 2026 : les annuaires mcp.so et smithery.ai, le registre officiel modelcontextprotocol/servers d'Anthropic sur GitHub, et le bouche-à-oreille via blogs, threads X et newsletters spécialisées. Sans publication sur au moins un des trois, votre MCP reste invisible.

Le code d'amphi-mcp est ouvert sur GitHub : github.com/Oliviercreativ/amphi-mcp. Le package npm : amphi-mcp (license MIT). Si vous voulez publier un MCP pour votre propre produit et que vous cherchez un accompagnement technique ou stratégique, on peut en parler — contact ou prendre rendez-vous.