MCP ou API REST pour ton agent : lequel lui donner, et quand

Donne MCP à ton agent quand il doit découvrir ce qu'il peut faire, et une API REST quand tu le sais déjà. MCP t'apporte la découverte et un seul flux d'auth, et coûte du contexte à chaque session. Un script qui publie de la même façon chaque nuit paie ce coût pour rien. Voici la ligne de partage, chiffres à l'appui.

MCP vs API : le tableau

Les deux parlent au même serveur. La différence, c'est qui lit la documentation : le modèle, ou toi.

Serveur MCP vs API REST : ce qui change vraiment à l'exécution

MCP est un protocole JSON-RPC 2.0 en deux couches : une couche de données qui définit les primitives, et une couche de transport qui est soit stdio pour un processus local, soit Streamable HTTP pour un processus distant. Un serveur expose trois choses : des outils (des fonctions que le modèle peut appeler), des ressources (des données qu'il peut lire) et des prompts (des modèles). Le client appelle tools/list pour découvrir ce qui existe, puis tools/call pour en exécuter un. Vérifié sur le site de la spec le 9 octobre 2026.

Cette étape tools/list, c'est tout le sujet. Une API REST a les mêmes opérations, mais la liste vit dans ta tête et dans ton code. Avec MCP, la liste arrive dans la fenêtre de contexte du modèle, en entier, avant même qu'il ait décidé s'il en avait besoin.

Depuis la version du protocole 2026-07-28, le protocole est sans état : chaque requête transporte la version et les capacités dans _meta, et server/discover remplace l'ancien handshake. Conséquence concrète pour toi : un serveur MCP distant peut tourner derrière un load balancer sans sticky sessions, et la liste d'outils revient avec un indice de cache ttlMs, donc un client bien conçu ne la recharge pas à chaque tour.

Ce que fait un agent avec 103 outils

Voici le cas concret. Le serveur MCP de PlugKit expose 103 outils et 3 workflows, vérifiés sur la page des outils le 9 octobre 2026. Ils sont regroupés : 18 pour les campagnes, 13 pour les posts, 12 pour les pubs Meta, 10 pour les comptes et connexions, 9 pour la messagerie, 7 pour les analytics, 7 pour l'engagement, jusqu'à 2 pour la recherche.

Un agent à qui on demande de « répondre aux commentaires de mon dernier Reel » a besoin de peut-être quatre de ces 103 outils. Les 99 autres sont quand même entrés dans son contexte, avec leurs noms, leurs descriptions et leurs schémas d'entrée. C'est ça, la taxe.

Trois choses réduisent la facture, et toutes les trois existent déjà :

1. Scopes. Une session qui n'a que mcp:read ne se voit jamais enregistrer les outils d'écriture, donc la liste rétrécit avant même d'atteindre le modèle. Les scopes sont mcp:read et mcp:write, documentés dans la présentation du MCP.
2. Workflows. PlugKit en fournit trois (publish, inbox, report) que les clients exposent sous forme de slash commands. Une seule commande remplace une chaîne d'appels d'outils que le modèle devrait sinon planifier : moins de tours, moins de suppositions erronées.
3. Découverte progressive. La spec prévoit un pattern pour ça : un client qui fédère de nombreux serveurs charge les outils à la demande au lieu de tout charger d'emblée. Que tu en profites dépend de ton client, pas du serveur.

Un serveur avec quatre fois plus d'outils a un problème quatre fois plus gros. J'ai compté 496 outils sur le MCP d'un concurrent dans le comparatif des serveurs MCP pour les réseaux sociaux, de quoi étouffer la conversation qu'il est censé servir.

Quand utiliser MCP

Donne MCP à l'agent quand au moins un de ces points est vrai :

• L'action suivante dépend de ce qu'il lit. Trier une boîte de réception, décider quel commentaire mérite une réponse, remarquer qu'un post a échoué et choisir un autre compte. Tu ne peux pas énumérer ces branches à l'avance, et c'est exactement à ça que sert un modèle.
• Un humain est dans la boucle. Quelqu'un tape « publie ça sur Instagram et LinkedIn à 9h ». MCP transforme cette phrase en appels sans que tu aies à livrer une UI.
• Tu ne veux pas détenir d'identifiants. Avec OAuth 2.1 et PKCE, le client ne stocke jamais de secret longue durée. L'utilisateur donne son accord sur un écran de consentement et le révoque de la même façon.
• Les capacités évoluent. Un serveur qui ajoute des outils est utilisé sans que tu aies à sortir une nouvelle version.

Le connecter tient en une ligne dans Claude Code : claude mcp add --transport http --scope user plugkit https://api.plugkit.co/mcp, puis /mcp pour t'authentifier. Cursor, VS Code, les apps Claude et ChatGPT en mode développeur prennent tous la même URL, d'après la doc des clients, vérifiée aujourd'hui.

Quand lui donner plutôt l'API REST

Donne-lui HTTP quand le travail est décidé avant que l'agent tourne :

• Publication programmée. Le payload est connu, les cibles sont connues. Un POST s'en charge en 200 ms, sans modèle dans la boucle et sans coût en tokens : POST /v1/posts avec accountIds et publishNow, documenté dans le guide de publication.
• Tu as besoin de tests. Un test unitaire vérifie un code de statut. Il ne peut pas vérifier qu'un modèle choisira create_post plutôt que publish_post un mauvais jour.
• Volume. Des milliers d'appels par heure via un modèle, c'est une facture, pas une architecture.
• Gestion stricte des erreurs. PlugKit renvoie 402 quand un quota de plan ou un plafond de dépenses bloque un appel, 429 quand tu es rate-limité, 404 au lieu de 403 pour les ressources qui ne t'appartiennent pas. Ton code peut temporiser sur un 429 et lever une alerte sur un 402. Un modèle, lui, lira parfois 402 et réessaiera.

Le détail utile : sur PlugKit, chaque outil MCP correspond à un endpoint REST avec le même vocabulaire et les mêmes ids. Ce n'est donc pas l'un ou l'autre. Tu prototypes dans l'agent, tu lis les ids qu'il a renvoyés, puis tu passes la moitié répétitive dans du code sans rien réapprendre.

Donne-lui les deux, répartis selon le déterminisme

Ce que je fais vraiment tourner, et ce que je recommanderais à quiconque construit sur une API de réseaux sociaux : le code gère tout ce qui est programmé et répétitif, l'agent gère tout ce qui est conversationnel et ambigu.

Côté agent, la config est la même quel que soit ton client : lis Claude en social media manager pour ce que le modèle gère bien et ce que je refuse de lui confier, et comment donner à un agent IA l'accès aux réseaux sociaux pour la mécanique en dessous.

Là où MCP est vraiment moins bon : tu perds le déterminisme, tu paies en contexte, et tu ne peux pas facilement comparer deux exécutions. Quiconque te dit que MCP remplace ton client d'API te vend un protocole, pas une architecture.

Combien ça coûte

PlugKit coûte 49 $ par mois pour 5 comptes connectés, résiliable à tout moment, ou 97 $ par mois pour 30. Le serveur MCP et l'API REST sont le même produit au même prix, donc le choix ci-dessus est purement technique. Sept jours gratuits, sans carte, avec un compte connecté pendant l'essai. Le seul supplément facturé à l'usage, c'est X : les appels sont refacturés au tarif de X, 0,005 $ pour lire un post et 0,015 $ pour en publier un, avec un plafond de dépenses mensuel de 20 $ par compte par défaut, tant que tu n'as pas fixé le tien. Chiffres tirés de la page de facturation, vérifiés le 9 octobre 2026.

FAQ

Quelle est la différence entre MCP et une API ?

Une API, c'est l'interface ; MCP est une façon standard de confier cette interface à un modèle. Un serveur MCP se place presque toujours devant une API REST et expose les mêmes opérations sous forme d'outils que le modèle découvre à l'exécution avec tools/list, au lieu d'endpoints que tu appelles depuis ton code. MCP apporte la découverte et un flux d'auth uniforme, et coûte du contexte.

MCP est-il meilleur qu'une API REST pour les agents ?

Seulement quand l'agent doit choisir. Si la séquence d'appels est connue avant l'exécution, un client REST est plus rapide, moins cher, testable et déterministe. Si le prochain appel dépend de ce que le précédent a renvoyé, MCP vaut son coût en contexte.

Quand faut-il utiliser MCP ?

Quand un humain parle à l'agent, quand la prochaine action dépend de données que l'agent vient de lire, quand tu préfères ne pas stocker de clé API longue durée, ou quand la liste d'outils change sans que tu aies à livrer une nouvelle version. Les appels programmés, identiques et à gros volume sont le cas inverse.

Est-ce que MCP consomme beaucoup de tokens ?

Chaque définition d'outil de la liste entre dans le contexte : nom, description et JSON Schema. Sur un serveur à 103 outils, c'est un vrai surcoût à chaque session. Réduis-le avec un scope en lecture seule, qui masque complètement les outils d'écriture, avec des workflows côté serveur qui regroupent plusieurs appels en une seule commande, et avec un client qui fait de la découverte progressive.

Est-ce que je peux utiliser MCP et l'API REST en même temps ?

Oui, et tu as intérêt à le faire. Sur PlugKit, chaque outil MCP correspond à un endpoint REST avec les mêmes ids, donc un agent peut explorer pendant que ton cron job publie sur les mêmes comptes. Les scopes et les clés sont séparés : l'agent peut être en lecture seule pendant que ton code garde l'accès en écriture.

AB

Antoine BlancoFondateur de PlugKit. Gère ses propres comptes Instagram, YouTube et X via l'API et le serveur MCP décrits ici.