Un tech lead vous dit "il faut qu'on passe nos intégrations Claude sur MCP". Vous demandez ce que vous avez aujourd'hui : 4 tools custom branchés via function calling, ça tourne en prod depuis huit mois. Réponse : "Oui mais MCP c'est mieux."

Même piège que sur l'Agent SDK. La phrase "c'est mieux" cache le fait que personne dans la pièce n'a vraiment articulé ce que MCP est censé résoudre. Et quand on ne sait pas ce qu'on résout, on migre pour rien.

MCP ne remplace pas function calling. Il standardise comment vos tools sont exposés, pas comment ils sont appelés.

Ce qu'est vraiment MCP (et ce qu'il n'est pas)

MCP, pour Model Context Protocol, est un protocole client/serveur ouvert publié par Anthropic fin 2024 (spec officielle). Il définit une interface standard pour qu'un LLM découvre et invoque des tools, des ressources (données accessibles en lecture) et des prompts. Claude Desktop, Claude Code, Cursor, Zed et un paquet d'autres clients l'implémentent déjà. L'écosystème de serveurs (GitHub, Notion, Slack, Postgres, Linear, Filesystem) grossit chaque semaine.

Le problème qu'il résout est concret. Avant MCP, vous aviez un problème en N×M : N modèles LLM, M tools internes, chaque combinaison demandait une intégration custom. Avec MCP, ça devient M+N : votre tool expose une fois une interface MCP, n'importe quel client compatible peut s'y brancher.

Ce que MCP n'est pas : un nouveau modèle, un remplaçant de function calling, ou une couche d'orchestration. Sous le capot, quand Claude appelle un tool exposé via MCP, c'est toujours du function calling classique. La différence est dans la manière dont le tool est découvert et négocié, pas dans l'inférence.

MCP, ce n'est pas une feature du modèle. C'est une prise de courant standardisée pour vos tools.

Une prise ne sert à rien quand vous n'avez qu'un appareil et un mur. Elle paie le jour où plusieurs appareils ont besoin du même circuit.

L'orchestration (boucles d'agent, sous-agents, gestion de contexte longue), c'est l'Agent SDK. J'ai détaillé la différence dans cet article sur l'Agent SDK Anthropic. MCP et SDK sont des couches complémentaires, pas concurrentes.

Quand ça vaut le coup

Trois cas où MCP fait gagner du temps. Pas du "nice to have". Des cas où la standardisation arrête d'être théorique et économise vraiment du code.

Réutiliser un tool sur plusieurs clients LLM

Vous avez un tool interne qui requête votre base produit. Aujourd'hui, votre PM l'utilise depuis Claude Desktop pour analyser le catalogue, vos devs l'utilisent depuis Claude Code, et vous voulez aussi le brancher dans une app interne maison. Sans MCP, vous écrivez trois intégrations. Avec MCP, vous écrivez un serveur, et les trois clients s'y connectent. Ce cas-là est précisément celui où le standard paie.

Profiter d'un écosystème grandissant

Vous voulez que Claude lise vos issues GitHub, vos pages Notion, vos messages Slack ou votre Postgres. Tous ces serveurs MCP existent déjà, officiels ou communautaires, certains maintenus par les éditeurs eux-mêmes. Vous installez, vous configurez les credentials, vous branchez. Coder vous-même ces intégrations en function calling, c'est faisable, mais c'est du temps que personne ne vous remboursera.

Découpler équipe-tool et équipe-app

Pattern qu'on voit dans les boîtes un peu structurées : une équipe data possède une source de vérité (data warehouse, API interne, catalogue), une autre équipe construit des apps LLM dessus. Sans MCP, chaque app duplique la logique d'accès, et chaque évolution du tool casse plusieurs apps. Avec MCP, l'équipe data possède un serveur, les équipes app s'y branchent. Le contrat est clair, les changements sont versionnés, les responsabilités sont nettes.

Quand ça n'apporte rien

Trois anti-cas. MCP n'est pas gratuit. Ça ajoute un transport, un serveur à déployer, une spec à suivre. Si vous n'en avez pas besoin, c'est de l'overhead pur.

Une seule app, deux tools maison

Votre app Claude appelle deux tools que vous avez écrits, qui n'ont aucune vocation à être réutilisés ailleurs. Mettre du MCP entre les deux, c'est ajouter un transport, un serveur à héberger, des credentials à gérer, pour gagner zéro portabilité. Function calling brut sur l'API Claude fait le job en moins de code et avec moins de surface d'attaque.

Tools ultra-spécifiques sans réutilisation prévue

Un tool qui fait un calcul métier propre à votre domaine, qu'aucune autre équipe ni aucun autre client n'aura jamais à invoquer, c'est par définition hors-cible MCP. Le standard sert à factoriser ce qui se réutilise. Quand rien ne se réutilise, le standard est un coût pur.

Latence ultra-critique

MCP introduit un hop transport (stdio, SSE ou HTTP selon la config) entre le LLM et le tool. Sur la majorité des cas, c'est invisible. Sur un agent temps réel où chaque milliseconde compte (trading, voice agent latence-sensible, contrôle industriel), ce hop peut se voir. Ce n'est pas un bloquant absolu, c'est un paramètre à mesurer avant de migrer.

Le piège classique

Pattern symétrique, comme pour l'Agent SDK, dans les deux sens.

Premier sens : tout migrer "parce que c'est le standard". Une équipe lit la doc, décide que MCP est la nouvelle façon de faire, et passe trois mois à réécrire des intégrations qui marchaient parfaitement, sans aucun nouveau consommateur en vue. Au bout du compte, même fonctionnalité, plus de code, plus de surface à maintenir, et un transport en plus à débugger.

Deuxième sens : refuser MCP par principe et coder son propre protocole interne. "On va faire notre standard maison." Six mois plus tard, vous découvrez que vous avez réinventé MCP en moins bien, sans la communauté, sans les serveurs existants, et que votre nouvelle équipe Claude Code ne peut rien brancher dessus.

Le standard, c'est l'option par défaut quand vous prévoyez plusieurs consommateurs. Pas une religion.

La bonne question n'est jamais "MCP est-il moderne". C'est "ai-je plus d'un consommateur à servir avec ce tool, aujourd'hui ou dans les douze mois".

Mes 3 questions de décision

Avant de partir sur MCP, ou de migrer du function calling existant, posez-vous ces trois questions dans cet ordre :

  1. Mes tools ou data sources seront-ils consommés par plus d'un client LLM (Claude Desktop, Claude Code, app interne, IDE) ?
  2. Existe-t-il déjà un serveur MCP officiel ou communautaire qui couvre ce que je veux brancher ?
  3. Ai-je besoin de séparer l'équipe qui produit le tool de celle qui produit l'app LLM ?

Si deux réponses sur trois sont oui, MCP paie. Sinon, function calling direct suffit, et vous gagnez en simplicité ce que vous perdez en portabilité théorique.

Pour conclure

MCP et Agent SDK sont souvent cités ensemble, et souvent confondus. Ce sont deux couches distinctes. MCP est la prise : il standardise comment vos tools sont exposés à un LLM. L'Agent SDK est le moteur : il orchestre la boucle qui appelle ces tools, gère le contexte long, délègue à des sous-agents. Vous pouvez utiliser l'un sans l'autre, ou les deux ensemble. Mais la décision se prend séparément, parce que les questions sont différentes.

Sur les projets Claude qui passent sur ma table, le réflexe sain est le même qu'avec n'importe quel standard émergent : adopter quand un consommateur supplémentaire est prévu, attendre tant qu'il n'y en a qu'un. La hype dit l'inverse. La hype a tort.

Si vous hésitez sur le rôle de MCP dans votre stack Claude, je fais ce diagnostic en 30 minutes. Direction la page consultant Claude pour voir comment je travaille, ou le formulaire de contact si vous voulez attaquer directement.