MCP vs curl: do you even need a server to call an API from an agent

Quand vous câblez des appels API dans un agent LLM, la question mcp vs curl finit par surgir. Les deux chemins aboutissent au même endpoint HTTP, mais l'abstraction, le coût en tokens et le poids opérationnel sont complètement différents. D'un côté, curl (ou fetch, httpx, n'importe quel client HTTP) envoie une requête brute et renvoie la réponse. De l'autre, MCP expose des capacités structurées et schéma-validées que le runtime LLM peut interroger dynamiquement.

La confusion est compréhensible: les deux font calling an API from an agent, et depuis que MCP a été ratifié en novembre 2024, il s'est retrouvé dans assez de stacks pour rendre la comparaison inévitable. Cet article établit un cadre de décision clair.

The mcp vs curl question: two different abstraction levels

Comparer MCP à curl, c'est comparer un menu de restaurant à une requête en cuisine. Curl est un client HTTP: vous lui donnez une URL, des headers, un payload, il vous renvoie une réponse. MCP (Model Context Protocol) est un protocole de découverte et d'exposition de capacités pour les LLM: le serveur annonce ses outils avec leurs schémas, l'agent en runtime sait quoi appeler sans que vous ayez hardcodé ce schéma dans le prompt.

La spécification MCP 1.0 a été ratifiée en novembre 2024 par Anthropic. D'ici mi-2026, elle s'est imposée comme la couche d'interface standard dans des milliers de stacks d'agents, de Claude Desktop aux pipelines custom sur LangGraph ou LlamaIndex. Ce déploiement massif explique pourquoi le débat mcp vs curl revient si souvent: vous voyez les deux options dans les mêmes tutoriels, parfois dans la même semaine.

La confusion vient d'une vraie ressemblance de surface. Un tool call MCP déclenche in fine un appel HTTP vers une API tierce. Un appel curl fait exactement la même chose. Mais l'endroit où se trouve la connaissance de cet appel est radicalement différent. Avec curl, elle est dans votre prompt ou dans le code de l'orchestrateur. Avec MCP, elle est dans le schéma du serveur, interrogeable dynamiquement par le modèle.

Cette différence détermine si votre agent peut découvrir un nouvel outil sans recompilation, si les résultats sont typés ou des strings brutes à parser, et combien de tokens votre contexte consomme avant même la première requête réelle.

Token overhead: what MCP scaffolding costs per agent call

C'est le chiffre que la plupart des tutoriels d'onboarding MCP passent sous silence: le tool call overhead du scaffolding.

Chaque outil exposé par un serveur MCP injecte son schéma dans le contexte de l'agent. Une description d'outil simple (nom, description, 3 à 4 paramètres) pèse entre 50 et 200 tokens. Un serveur avec 10 outils consomme donc 500 à 1500 tokens de contexte input avant que l'agent n'ait encore rien demandé.

Estimation de coût au tarif Claude Sonnet (environ $3 par million de tokens input en Q1 2026):

Scénario	Overhead tokens/session	Coût pour 1000 sessions/jour
MCP (10 outils, ~1000 tokens schéma)	1000	~$3
Curl direct	0	$0

Sur un agent à faible volume, c'est négligeable. Sur un pipeline de traitement batch à 100 000 appels par jour, $300 de tokens non-productifs commencent à peser dans votre budget. La bonne pratique dans les stacks haute fréquence de 2025-2026 est de n'exposer via MCP que les outils effectivement utilisés dans la session, pas la totalité du catalogue disponible.

What MCP gives you that bare curl cannot

Le cas curl est convaincant sur les coûts et la simplicité. Mais MCP offre trois propriétés qui n'ont pas d'équivalent propre en direct API access.

Découverte d'outils en runtime. Avec curl, votre agent sait quoi appeler parce que vous avez hardcodé ce savoir dans le prompt ou dans le code. Ajoutez un outil: vous recompilez ou mettez à jour le prompt. Avec MCP, l'agent interroge le serveur à l'initialisation et reçoit la liste schéma-validée des capacités disponibles. Un nouvel outil déployé côté serveur est immédiatement accessible sans toucher au code de l'orchestrateur.

Résultats structurés, pas de string-parsing. Un appel curl renvoie du JSON brut, du HTML ou du XML. Votre pipeline doit extraire, valider, transformer. Un outil MCP renvoie un résultat typé conforme au schéma déclaré. Moins de prompts de parsing intermédiaires, moins de surface d'erreur sur les cas limites.

Composabilité multi-transports. MCP définit un protocole commun au-dessus de plusieurs transports: stdio pour les processus locaux, SSE pour le streaming, HTTP pour les serveurs distants. Vous pouvez mixer des outils provenant de sources différentes avec une interface unique. Le support SSE est particulièrement utile: il réduit le temps jusqu'au premier token sur des réponses d'API longues d'un ordre de grandeur par rapport à une approche polling classique. Honeycomb a documenté cette propriété de composabilité comme l'un des différenciateurs nets de MCP pour les pipelines d'observabilité.

When direct HTTP calls beat MCP servers

Plusieurs situations font que les agent HTTP requests directs gagnent sans discussion.

Les intégrations ponctuelles sont le cas le plus évident. Si votre agent appelle une seule API une fois, monter et maintenir un processus serveur MCP est disproportionné. Un appel fetch ou une commande curl dans le prompt bash de l'agent suffit, sans dépendance supplémentaire.

La latence est un deuxième critère réel. Un appel subprocess curl ajoute environ 2ms de latence. Un round-trip vers un serveur MCP local (démarrage de processus, handshake protocole, réponse) pèse 50 à 300ms. Pour les pipelines temps-réel ou à SLA strict, la différence est concrète et mesurable.

Si votre agent a déjà un outil bash fonctionnel et que curl est installé sur la machine hôte, le besoin d'un wrapper MCP disparaît. Vous avez le calling an API from an agent sans aucune dépendance à un daemon externe. Comme le note systemprompt.io, curl fonctionne tant que curl est installé.

Enfin, dans les stacks cost-cappées où chaque token compte, éliminer 500 à 1500 tokens de scaffolding par session est une optimisation réelle. La règle pratique: une seule API à appeler et pas de besoin de découverte dynamique, le direct API access est votre meilleur choix.

The curl-via-MCP paradox (and what it tells us about 2026 tooling)

Voici l'ironie révélatrice de l'écosystème actuel: des développeurs ont construit des serveurs MCP dont le seul rôle est d'encapsuler curl. Le dépôt mcp-curl de 247arjun sur GitHub, les listings sur mcpmarket.com, la collection mcpx d'arcade.dev. Au moins cinq projets publics existent uniquement pour faire de mcp vs curl une fausse alternative, en déclenchant des agent HTTP requests curl depuis un client MCP.

Ce paradoxe révèle quelque chose d'important sur l'état de l'écosystème en 2026: MCP a gagné la couche d'interface. Les développeurs veulent la découverte et la composabilité de MCP même quand l'opération sous-jacente est un HTTP trivial. La valeur n'est pas dans le transport (qui reste HTTP dans les deux cas), elle est dans le contrat que MCP établit entre l'agent et ses capacités. En fait, j'ai commencé par penser que ces wrappers étaient absurdes, mais après avoir creusé un peu, je comprends mieux l'intérêt. Le menu structuré permet à votre agent de composer des réponses complexes sans que vous ayez à reconfigurer l'orchestrateur à chaque évolution de votre stack d'APIs.

D'ailleurs, il y a une analogie qui marche bien: MCP est le menu, curl est la cuisine. Le menu liste les plats disponibles avec leurs ingrédients (schéma). La cuisine exécute la commande (appel HTTP). Un restaurant peut très bien exister sans menu formalisé (agent bash avec curl direct), c'est efficace pour un usage simple. Mais à l'échelle, le menu structuré change tout.

La tendance de fond pour la deuxième moitié de 2026: les abstractions MCP vont se consolider autour de la découverte et de la composabilité, tandis que les transports sous-jacents resteront des clients HTTP banals. Les deux patterns coexistent et se complètent.

Key takeaways

MCP et curl ne sont pas des alternatives exclusives. Pour les appels ponctuels vers une ou deux APIs, le direct API access reste plus simple, plus rapide et moins coûteux en tokens. MCP justifie son tool call overhead dans les stacks multi-outils où la découverte dynamique et les résultats typés réduisent la surface d'erreur et le coût de maintenance. En 2026, MCP a gagné la couche d'interface; le transport est HTTP de toute façon.

---

MCP injects 500-1500 tokens of schema overhead per session on a 10-tool server, while curl calls cost zero upfront. The CLI Blueprint in the welcome kit shows you how to wire direct API calls as agent tools without the protocol tax, then know exactly when MCP's cost justifies itself.

→ Get the welcome kit