Qu’est-ce que MCP et pourquoi votre ChatGPT App en a besoin

1. Pourquoi faut‑il un protocole séparé

Dans ce module, nous allons enfin comprendre ce qu’est le MCP (Model Context Protocol) et comment il s’insère dans la pile d’une ChatGPT App. Commençons par fixer la place du MCP dans l’architecture, le comparer à un « REST classique » et passer en revue les principales entités du protocole : tools, resources et prompts.

Imaginez que vous développez un service web classique. Par bonne vieille habitude, vous exposez une API REST : vous avez /api/gifts, /api/users, /api/orders, chacun avec son format d’entrée/sortie, ses codes d’erreur et son système d’authentification. C’est familier, mais il y a un bémol : à chaque client vous devez expliquer ce que vous avez implémenté et comment. Documentation, OpenAPI, exemples, SDK — tout cela est nécessaire, parce que vous avez inventé vous‑même le format de l’API.

Avec une ChatGPT App, la situation se complique. Votre client n’est pas seulement le front‑end, c’est aussi le modèle lui‑même. Il doit :

• connaître quelles opérations sont disponibles ;
• comprendre quels arguments sont nécessaires à chaque opération ;
• appeler ces opérations au fil du dialogue, parfois plusieurs fois, parfois avec des paramètres différents ;
• interpréter la réponse structurée et décider quoi afficher à l’utilisateur et quoi n’utiliser que comme contexte pour la réplique suivante.

Si chaque développeur invente son propre format d’API, le modèle finira en enfer d’intégration : pour chaque App, il faudrait un client sur‑mesure, beaucoup de « glue » et une logique fragile. L’idée d’un protocole résout ce problème.

MCP (Model Context Protocol) est une spécification ouverte d’un moyen standardisé pour qu’un client LLM (ChatGPT, plugin IDE, agent, etc.) communique avec votre serveur d’outils et de données. Il définit un langage commun dans lequel le serveur déclare ses outils, ressources et prompts, et le client — les appelle et reçoit les résultats.

Intuitivement, MCP est le port USB‑C du monde de l’IA : si vous fabriquez une « clé USB » (service, base de données, CRM, moteur de recherche), vous implémentez un connecteur standard unique. Ainsi, n’importe quel « ordinateur portable » (ChatGPT, un autre agent, une IDE) peut se connecter sans câble sur‑mesure.

2. Vue d’ensemble : où se situe MCP dans l’architecture d’une ChatGPT App

Pour fixer la vision, reprenons l’architecture déjà connue, mais cette fois avec une couche MCP explicite.

L’image mentale actuelle, vous l’avez déjà vue : l’utilisateur échange avec ChatGPT, un widget (Apps SDK) est rendu dans le dialogue, et quelque part à l’extérieur vit votre back‑end. Ajoutons maintenant MCP et répartissons le tout par couches.

Voici un schéma simplifié :

Utilisateur
   ↓ (langage naturel)
ChatGPT (modèle + UI)
   ↓ (appels d’outils via MCP)
Client MCP intégré à ChatGPT
   ↓ (JSON-RPC, MCP)
Votre serveur MCP (back‑end)
   ↓
Votre base de données / API externes / files d’attente

Par « client MCP intégré à ChatGPT », on entend la partie interne de la plateforme qui parle à votre serveur MCP via le protocole : elle fait de la découverte, appelle les outils et lit les ressources.

Du point de vue de l’Apps SDK, une ChatGPT App minimale se compose de trois éléments. Le premier — un serveur MCP qui déclare des outils et retourne des données structurées. Le deuxième — un bundle UI (widget) rendu dans ChatGPT et qui lit ces données via window.openai. Le troisième — le modèle lui‑même, qui décide quand appeler quel outil et comment répondre à l’utilisateur.

Il est important de voir ceci : dans les modules précédents, vous avez surtout travaillé au niveau de l’Apps SDK et du widget, donc dans la partie supérieure du schéma. À présent, nous descendons au niveau du serveur MCP — c’est votre « langue officielle » pour dialoguer avec ChatGPT et tout autre client qui décidera d’utiliser votre App.

3. MCP vs « REST classique » : quelle différence

Sur le schéma ci‑dessus, nous avons positionné MCP dans l’architecture d’une ChatGPT App. Comparons maintenant prudemment l’approche « son propre REST » et MCP, afin de comprendre pourquoi, dans le contexte des ChatGPT Apps, la seconde l’emporte presque toujours.

Dans l’approche REST, vous concevez les endpoints et les formats de requêtes/réponses comme cela vous convient. Pour travailler avec vous, le client doit connaître les URL, méthodes, schémas et codes d’erreur. Parfois OpenAPI aide, parfois vous balancez juste un exemple de requête dans un README. Le modèle, en soi, ne comprend rien de tout cela : il lui faut une couche de code qui transformera « trouve un cadeau pour ma mère de 50 ans » en une requête HTTP concrète, puis retransformera la réponse JSON en données adaptées au dialogue.

Avec MCP, c’est différent. Le protocole spécifie lui‑même :

• comment le client peut découvrir la liste de vos outils ;
• comment décrire les arguments et les résultats via JSON Schema ;
• comment décrire les ressources et les prompts ;
• à quoi ressemble l’appel d’un outil et sa réponse.

Grâce à cela, ChatGPT et les autres clients MCP peuvent automatiquement :

• exécuter un discovery — découvrir vos tools/resources/prompts ;
• construire un schéma interne de paramètres pour chaque outil ;
• les appeler sans logique client hardcodée sur‑mesure ;
• mettre en cache les métadonnées et les utiliser pour la recherche et le classement des applications.

On peut résumer les différences dans un petit tableau.

Pour le dire de manière imagée : REST — c’est « chacun pour soi », MCP — c’est « un accord entre tous les acteurs de l’écosystème sur la façon d’échanger avec le modèle et les données ».

4. Entités principales de MCP : tools, resources, prompts

Nommons maintenant les trois protagonistes de MCP : les outils, les ressources et les prompts.

Tools : des actions auxquelles vous êtes déjà habitué

Vous avez déjà rencontré des tools dans le module 4 : nous y avons décrit un outil, lui avons donné un nom, une description et un JSON Schema d’arguments, puis le modèle l’a appelé via callTool. Au niveau MCP, un outil est une opération côté serveur avec un contrat clair :

• nom et description (pour le modèle et pour l’UX/la découverte) ;
• JSON Schema pour les arguments ;
• JSON Schema ou description de la structure du résultat ;
• métadonnées supplémentaires (par exemple, association à un composant UI spécifique dans l’Apps SDK).

Un serveur MCP doit au minimum savoir répondre à « la demande de liste d’outils » et traiter « l’appel d’un outil », en renvoyant un résultat structuré.

Dans notre application d’exemple d’assistant cadeaux, nous avons par exemple un outil suggest_gifts, qui prend l’âge, le genre, le budget et quelques préférences, puis renvoie une liste de cadeaux recommandés.

Un croquis TypeScript d’un tel outil côté serveur MCP pourrait ressembler à ceci (pseudo‑code/ébauche) :

// Pseudo‑code, API SDK non définitif
const suggestGiftsTool = defineTool({
  name: "suggest_gifts",
  description: "Propose des idées de cadeaux selon les paramètres du destinataire",
  inputSchema: z.object({
    age: z.number(),
    relation: z.enum(["friend", "partner", "parent"]),
    budgetUsd: z.number(),
  }),
  handler: async (input) => {
    // TODO: votre logique métier
    return { items: [] };
  },
});

Nous détaillerons les signatures réelles dans les prochaines leçons ; ici, l’idée importante est la suivante : un outil n’est pas juste un endpoint REST, c’est un élément de protocole avec un schéma déclaré.

Ressources (resources) : des données accessibles par ID/URI

Les ressources (resources) dans MCP sont une façon de décrire les données disponibles : fichiers, répertoires, enregistrements BD, pages wiki, voire résultats d’index de recherche. Le client peut :

• obtenir la liste des ressources ;
• lire une ressource donnée par ID/URI ;
• parfois — effectuer une recherche parmi elles.

Contrairement aux tools, qui « font quelque chose », les resources « stockent quelque chose ». Par exemple, dans une Gift‑App, vous pouvez représenter le catalogue produits comme la ressource gift_catalog, à laquelle le modèle se réfère pour connaître les catégories disponibles, les filtres, les gammes de prix, etc.

En code, cela peut ressembler conceptuellement à ceci :

const giftCatalogResource = defineResource({
  uri: "catalog://gifts",
  description: "Catalogue de cadeaux disponibles pour la recommandation",
  read: async () => {
    // Retourne la structure du catalogue
    return { categories: [], priceRanges: [] };
  },
});

Nous n’entrons pas encore dans le format des messages MCP, mais gardons à l’esprit que les ressources sont des entités adressables sur lesquelles le serveur MCP peut pointer, et que le client peut lire et utiliser comme partie du contexte.

Prompts : des consignes pré‑configurées

Les prompts dans le contexte MCP sont des modèles de requêtes ou d’instructions que le serveur peut fournir au client. Par exemple, vous pouvez déclarer un prompt gift_followup, qui décrit comment le modèle doit demander des précisions à l’utilisateur sur le destinataire du cadeau avant d’appeler l’outil.

Exemple typique dans l’esprit du protocole : le serveur fournit le nom du prompt, sa finalité et parfois des paramètres. Le client peut demander la liste des prompts, choisir celui qu’il faut et l’insérer dans la requête au modèle.

Pourquoi est‑ce utile à une ChatGPT App ? Premièrement, c’est une façon unifiée de réutiliser des consignes complexes entre différents clients. Deuxièmement, MCP rend ces prompts explicites et « sous contrat », plutôt que disséminés dans le code.

Capabilities : ce que votre serveur déclare supporter

Enfin, il existe un quatrième élément — les capabilities. C’est une simple déclaration : le serveur indique quelles entités il supporte (tools, resources, prompts, notifications, etc.) et quels appels précis il implémente. Pour le client, c’est un moyen d’éviter de deviner ce qui est possible et d’adapter proprement son comportement aux capacités du serveur.

En pratique, lorsque ChatGPT se connecte à votre serveur MCP, il commence par effectuer une « poignée de main », obtient la liste des capabilities, puis il demande : « OK, montre‑moi tes outils et tes ressources ».

5. Comment MCP s’intègre à votre App actuelle

Tout cela semble un peu abstrait, mais en réalité, vous avez déjà croisé MCP via l’Apps SDK. Commençons par comprendre comment tout cela s’articule avec ce que vous avez déjà écrit dans le cadre de l’Apps SDK. Reliions les entités que nous venons d’introduire à l’organisation actuelle de votre template d’App.

Rappelons la chaîne que vous avez déjà implémentée dans le template :

1. Le widget, via window.openai ou des hooks prêts à l’emploi, appelle callTool avec le nom de l’outil et les arguments.
2. L’Apps SDK dans ChatGPT transforme cela en un appel vers la partie serveur de l’App.
3. Le serveur exécute l’outil et retourne un ToolOutput, incluant structuredContent, content et _meta.
4. Le widget reçoit le ToolOutput et rend l’UI.

Le secret, c’est que les étapes 2–3 sont réalisées comme un dialogue via MCP. Votre template Next.js contient un endpoint (généralement app/mcp/route.ts ou similaire), qui est justement le serveur MCP. Il :

• enregistre vos outils ;
• les décrit via JSON Schema ;
• implémente les handlers ;
• répond à ChatGPT sur les requêtes MCP list tools et call tool.

Autrement dit, même avec le template, vous utilisez déjà MCP « automatiquement » : la majeure partie de la magie protocolaire est cachée dans le SDK.

Le module 6 est là pour cesser de traiter MCP comme une « boîte noire magique » et commencer à le concevoir consciemment :

• ajouter et versionner des outils ;
• utiliser des resources et des prompts, pas seulement des tools ;
• lire et comprendre les logs MCP ;
• si nécessaire, lancer des serveurs MCP séparés en dehors du template Next.js (par exemple, un service Python pour une charge de travail ML, ou un service distinct d’accès à une base d’entreprise).

6. MCP vu par différents rôles : product vs développeur

Il est utile d’exprimer séparément ce que MCP apporte à un product manager et à un ingénieur.

MCP pour le product

Du point de vue produit, MCP est un moyen de rendre votre service « plug‑and‑play » pour tout un zoo de clients : ChatGPT, autres clients LLM, plugins d’IDE, agents maison. En décrivant une fois les capacités du serveur sous forme d’un ensemble de tools/resources/prompts, vous permettez à n’importe quel client de :

• découvrir automatiquement votre service ;
• comprendre quelles tâches il résout ;
• appeler en toute sécurité les opérations nécessaires.

Dans le cas d’une ChatGPT App, cela augmente aussi la probabilité que votre application soit choisie : le modèle utilise les métadonnées de vos outils pour décider quand proposer votre App à l’utilisateur et comment la présenter.

En très court : MCP transforme votre service en brique standard de l’écosystème, et non en intégration sur‑mesure pour un ou deux clients.

MCP pour le développeur

Du point de vue ingénierie, MCP est un contrat et un protocole. Il répond aux questions :

• Dans quel format dois‑je déclarer un outil ?
• Comment décrire les arguments et renvoyer le résultat ?
• Comment le client saura‑t‑il que je supporte des ressources et des prompts ?
• À quoi ressemble le JSON qui transite sur le réseau ?

Avec un tel protocole, il devient plus simple de :

• développer des serveurs dans différents langages (des SDK officiels existent pour TypeScript et Python) ;
• déboguer l’application via MCP Inspector ou des outils analogues ;
• répartir les responsabilités entre équipes : l’une réalise le serveur MCP avec les données et outils, une autre — le widget via l’Apps SDK, une troisième — ses propres agents au‑dessus du même serveur MCP.

7. Petite perspective pratique : notre premier serveur MCP

Dans cette leçon, nous évitons volontairement les détails du format des messages et de l’implémentation serveur — ce sera l’objet des sujets suivants. Mais pour comprendre où l’on va, il est utile d’apercevoir la structure générale d’un serveur MCP minimal en TypeScript.

En pratique, la bibliothèque officielle MCP pour TypeScript fournit des primitives pour créer un serveur, enregistrer tools/resources/prompts et démarrer un transport (généralement HTTP ou SSE).

Un pseudo‑exemple pourrait ressembler à ceci :

// Exemple conceptuel, nous verrons l’API du SDK plus tard
import { createServer } from "@modelcontextprotocol/sdk";

const server = createServer({
  name: "gift-genius",
  version: "1.0.0",
});

// Nous enregistrons un outil
server.tool("suggest_gifts", {
  description: "Propose des cadeaux selon les préférences du destinataire",
  inputSchema: {/* ... */},
  handler: async (input) => {
    // votre logique
    return { items: [] };
  },
});

// Démarrons le transport (par exemple, HTTP)
server.listen(3001);

Point important : nulle part ici on ne mentionne ChatGPT, l’Apps SDK ou votre front‑end spécifique. Le serveur MCP est autonome. Il sait simplement répondre aux requêtes MCP. La ChatGPT App n’est qu’un type de client possible pour un tel serveur.

Dans le cadre du cours, nous resterons sur le template Next.js, où le serveur MCP vit comme une partie du projet, mais ce n’est pas la seule option.

8. MCP dans l’écosystème : Apps SDK, Agents SDK et ACP

Pour ne pas percevoir MCP comme une « fonctionnalité réservée à l’Apps SDK », il est utile de l’inscrire dans un tableau plus large.

Premièrement, l’Apps SDK s’appuie directement sur MCP comme pont standard entre ChatGPT et les services externes. La documentation officielle souligne que l’Apps SDK fonctionne avec n’importe quel serveur MCP. Le protocole lui‑même permet de décrire des outils, de renvoyer des données structurées et d’indiquer le composant à rendre dans l’UI.

Deuxièmement, l’Agents SDK, que vous verrez dans un module séparé, sait lui aussi se connecter à des serveurs MCP. Cela signifie qu’un même serveur MCP avec logique métier peut être utilisé :

• dans ChatGPT comme partie de votre App ;
• dans un agent autonome fonctionnant, par exemple, en tâche de fond dans votre produit ou en mode batch.

Troisièmement, l’ACP (Agentic Commerce Protocol), dont vous aurez besoin pour les achats et l’Instant Checkout, se construit logiquement sur l’approche MCP : le modèle et les agents appellent des outils de commerce également décrits via des contrats standardisés.

Ainsi, MCP devient le fondement sur lequel se construisent l’UI (Apps SDK), les scénarios agents (Agents SDK) et la partie commerce (ACP). Si vous maîtrisez MCP, tout le reste devient plus clair et prédictible.

Remarque : Formellement, l’ACP ne dépend pas de MCP en tant que spécification, mais dans une implémentation réelle, les outils ACP seront très probablement appelés par le modèle via des interfaces MCP. Les deux approches s’emboîtent très bien — l’attente ne devrait pas être longue.

9. Quelques exercices « mentaux » avant la pratique

Avant de plonger, dans la prochaine leçon, dans le format des messages MCP, il est utile de faire deux ou trois exercices mentaux. Cela aidera à « basculer » de « REST classique » vers « protocole + contrat ».

Imaginez que votre Gift‑App souhaite être connectée non seulement à ChatGPT, mais aussi à un plugin IDE pour VS Code et à un assistant interne d’entreprise dans Slack. Décrivez en une phrase ce qu’ils doivent tous savoir de votre service. La réponse sera probablement : « Nous avons un outil suggest_gifts avec tels paramètres, et un catalogue de cadeaux accessible via telle ressource ». C’est précisément ce que MCP formalise.

Essayez aussi de formuler en deux phrases :

• ce qu’est MCP pour le product de votre App (indice : une manière standard de « packager » des fonctionnalités pour divers clients) ;
• ce qu’est MCP pour le développeur (indice : un protocole JSON‑RPC avec des primitives claires tools/resources/prompts).

Si vous pouvez le faire sans hésiter — vous êtes déjà à mi‑chemin d’une pratique sûre de MCP.

S’il faut tout résumer en une phrase : MCP n’est pas une API de plus, mais un contrat fondamental entre votre logique et les clients LLM. Dans les prochaines leçons, nous regarderons à l’intérieur du protocole lui‑même : format des messages MCP, handshake/capabilities, et nous apprendrons à inspecter le trafic via des inspecteurs — pour que ces principes deviennent des outils concrets et pas des abstractions.

10. Erreurs et idées reçues courantes autour de MCP

Erreur n° 1 : considérer MCP comme « une couche d’API de plus au‑dessus de mon REST ».
La tentation existe parfois : « J’ai déjà un REST, je vais simplement ajouter un fin adaptateur qui transforme les appels MCP en REST et inversement, et on n’en parle plus ». Formellement, c’est possible, mais vous finissez alors souvent par « faire remonter » les particularités de l’ancienne API dans MCP : types étranges, réponses non structurées, absence de schémas explicites. L’adaptateur enfle avec le temps, et le bénéfice de MCP diminue. Mieux vaut considérer MCP comme le contrat principal, et l’ancien REST comme un détail d’implémentation interne, s’il vous est encore utile.

Erreur n° 2 : penser que MCP est « uniquement pour les ChatGPT Apps ».
MCP est un protocole ouvert et généraliste pour tous les clients LLM : ChatGPT, plugins d’IDE, agents autonomes. Si vous concevez un serveur MCP en ne visant qu’une seule App, vous vous limitez pour l’avenir. Il est bien plus rentable de penser dès le départ : « ce serveur pourra être utilisé par d’autres clients », et de concevoir les outils et ressources un peu plus universels.

Erreur n° 3 : ignorer JSON Schema et décrire les arguments “à la main”.
Même si le SDK permet parfois de passer « n’importe quel JSON », ne faites pas l’impasse sur la description des schémas d’arguments et de résultats. La capacité du modèle à appeler correctement votre outil en dépend directement, tout comme la qualité de l’autocomplétion et de la découverte, et la facilité de débogage via les inspecteurs. Des arguments non décrits ou mal décrits mènent droit à des erreurs de tool‑call mystérieuses.

Erreur n° 4 : percevoir MCP comme un « transport magique » et ne pas regarder les logs.
Tant que tout fonctionne, on a l’impression que MCP est une chose invisible dont on n’a pas à se soucier. Le problème, c’est qu’au premier incident, sans compréhension de la structure MCP, vous allez vous demander longtemps : « est‑ce l’Apps SDK ? le modèle ? mon back‑end ? ». L’habitude d’inspecter tôt les messages et logs MCP vous épargnera des heures d’errance.

Erreur n° 5 : tenter de concevoir un workflow complexe uniquement via REST, en ignorant les primitives MCP.
Quand apparaissent des scénarios en plusieurs étapes (recherche de cadeau → clarification des préférences → choix → commande), on est tenté de « faire un gros endpoint REST unique ». Dans le contexte des ChatGPT Apps, cela dégrade souvent la maîtrisabilité : le modèle comprend moins bien les étapes intermédiaires, et le client MCP perd la possibilité de réutiliser ressources et prompts. Il vaut bien mieux découper la fonctionnalité en plusieurs tools/resources bien décrits, et relier la logique via des prompts système et des descriptions correctes.