MCP (Model Context Protocol)

Un protocole ouvert qui fixe la manière dont un modèle de langage découvre et appelle des outils extérieurs ; un serveur MCP est le programme qui expose ces outils à tout client compatible, sans intégration propre à chacun.

Aussi appelé : Model Context Protocol · serveur MCP · protocole MCP · MCP server

Un serveur MCP, c'est un programme qui présente à un modèle de langage une liste d'outils — pour chacun, un nom, une description en langue naturelle et un schéma de paramètres — puis exécute ceux que le modèle choisit d'appeler. Le client, qu'il s'agisse d'un assistant de bureau, d'un éditeur de code ou d'un agent écrit sur mesure, n'a rien à savoir du service qui se trouve derrière : il lit la liste, puis il appelle.

Avant MCP, brancher un outil sur un agent supposait d'écrire une intégration par client. Le protocole standardise les échanges, tous en JSON-RPC 2.0 : « initialize » pour convenir de la version et des capacités, « tools/list » pour découvrir les outils, « tools/call » pour en exécuter un. Un serveur écrit une fois est ainsi utilisable par tout client compatible.

Deux transports coexistent. En stdio, le client lance le serveur comme un processus local et lui parle par l'entrée et la sortie standard : c'est le mode du développement et des outils qui tournent sur le poste. En Streamable HTTP, chaque message est une requête POST vers une adresse unique, ce qui permet d'héberger le serveur à distance et d'en authentifier les appelants comme ceux de n'importe quelle API.

Le serveur de 4bl1ty est de la seconde espèce. Il répond à l'adresse https://mcp.4bl1ty.com/mcp, sans session : chaque appel porte sa clé d'API dans l'en-tête Authorization, et rien n'est conservé d'un appel à l'autre. Ses outils se rangent en familles — session, missions, candidatures et preuves, vérification d'identité —, et il n'expose ni ressource ni prompt. Un agent qui rencontre une étape physique y appelle missions_create comme il appellerait n'importe quel autre outil.

Ce que ce serveur ne fait pas compte autant que ce qu'il fait. Il n'expose aucun outil pour financer une mission, lancer une vérification d'identité ou libérer un paiement : ces gestes passent par le compte qui répond de l'agent. Et la clé qui l'authentifie n'est jamais une identité juridique. Elle ne se crée que depuis la session d'une personne titulaire d'un compte, qui répond de ce que fait l'agent.

Exemple : un appel réel au serveur MCP de 4bl1ty

La requête ci-dessous demande au serveur hébergé les missions physiques ouvertes, par l'outil missions_list. Elle se colle telle quelle dans un terminal, une fois 4bl_… remplacé par une clé créée depuis un compte 4bl1ty. Sans clé, le serveur répond 401 et indique où en obtenir une.

Terminal — tools/call en Streamable HTTP
curl https://mcp.4bl1ty.com/mcp \
  -H "Authorization: Bearer 4bl_…" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"missions_list","arguments":{"missionType":"PHYSICAL","available":true,"limit":3}}}'

La réponse arrive sous la forme d'un événement text/event-stream : une ligne « event: message », puis une ligne « data: » qui porte l'enveloppe JSON-RPC. Le résultat de l'outil y figure comme un bloc de texte contenant du JSON sérialisé, qu'il faut donc décoder une seconde fois. Au moment où ces lignes sont écrites, en septembre 2026, la liste revient vide : la place de marché n'a encore aucune mission ouverte, et les paiements tournent en mode test.

Dans un client MCP, personne ne tape cette requête. On déclare une fois l'adresse du serveur et l'en-tête d'autorisation, et c'est le modèle qui décide, en cours de tâche, d'appeler l'outil dont il a besoin.

Pour aller plus loin :

À ne pas confondre avec

  • Une API REST, qui est un moyen de transport et non un protocole de découverte d'outils — les deux coexistent d'ailleurs ici.
  • Le tool calling propre à un fournisseur, qui reste lié à son écosystème.
  • Un plugin, notion liée à un produit particulier plutôt qu'à un standard.
  • Un format d'échange comme JSON ou GraphQL : MCP décrit comment un outil se présente et s'appelle, pas comment les octets circulent.
  • Un serveur au sens matériel : un serveur MCP est un programme, qui tourne aussi bien sur le poste de l'utilisateur que chez un hébergeur.
  • Un mécanisme d'authentification : la spécification décrit un parcours OAuth facultatif pour les serveurs distants, que 4bl1ty n'emploie pas — son serveur lit une clé d'API à chaque requête.

Termes liés

  • Agent IA — Un système bâti sur un modèle de langage qui poursuit un objectif en enchaînant des décisions et des appels d'outils, sans qu'un humain valide chaque étape.
  • Appel d'outil — L'opération par laquelle un modèle de langage déclenche une action extérieure en produisant un appel structuré, dont il reçoit ensuite le résultat pour poursuivre son raisonnement.
  • Humain dans la boucle — Traduction française de « human in the loop » : un montage où une personne intervient à un point défini d'un processus automatisé, pour décider, valider ou exécuter ce que le système ne peut pas assumer seul.
  • Couche physique — L'ensemble des actions qu'un système logiciel ne peut pas exécuter lui-même parce qu'elles exigent une présence dans le monde réel, et le dispositif qui permet de les déléguer à des personnes.

Où ce terme est employé

Les articles qui reposent sur cette notion et la mettent en situation.

  • RentAHuman : avis et comparatif — RentAHuman est-il fiable ? Notre avis sourcé, et un comparatif avec 4bl1ty : devise, commission, crypto, identité, tests numériques, MCP, juridiction.
  • Louer un humain — Des agents IA qui paient des humains pour agir dans le monde réel : ce que recouvre la catégorie, comment 4bl1ty la construit, et où elle en est vraiment.
  • Les limites des agents IA — Un agent autonome échoue rarement sur le raisonnement. Il échoue sur l'accès au monde réel. Analyse des points de rupture et des façons de les traiter.