1 · Architecture Hôte ↔ Client ↔ Serveur — flux JSON-RPC animé
MCP (Model Context Protocol — protocole de contexte de modèle) fait circuler des messages JSON-RPC 2.0 entre un Hôte (l'application), des Clients (un par serveur — relation 1:1 stricte) et des Serveurs (fournisseurs d'outils). Lancez un scénario et observez chaque message réel transiter sur le fil.
🖥️ HÔTE
🔗 CLIENT
stdio (JSON-RPC / stdin-stdout)
⚙️ SERVEUR
id + réponse attendue · notification = sans id ·
la négociation de capacités au handshake garantit la compatibilité évolutive.
2 · Tool, Resource ou Prompt ? Le sélecteur de primitive
La question d'examen n° 1 : la bonne primitive ne dépend pas de « lecture ou écriture », mais de qui contrôle l'invocation. Décrivez votre cas d'usage en répondant aux questions — ou chargez un cas pré-rempli — et obtenez la recommandation justifiée.
1. L'opération modifie-t-elle un état ou déclenche-t-elle un effet de bord (écrire, envoyer, rembourser…) ?
2. Qui doit décider du moment de l'invocation ?
3. La donnée doit-elle notifier ses changements en continu ?
3 · stdio vs Streamable HTTP — le comparateur de transport
Répondez aux cinq questions d'architecture : chaque réponse fait pencher la balance. Rappel : SSE seul est déprécié — remplacé par Streamable HTTP.
Matrice de référence (à connaître pour l'examen)
| Critère | stdio | Streamable HTTP |
|---|---|---|
| Localisation | Même machine que l'hôte | Machine distante / cloud |
| Utilisateurs | 1 (local) | N (mutualisé) |
| Authentification | Héritée du système d'exploitation | OAuth 2.1 / jetons bearer |
| Ressources locales | Accès direct | Impossible (ou via tunnel) |
| Déploiement | Avec l'application hôte | Service web opéré |
| Latence | Minimale (pas de réseau) | Dépend du réseau |
| Journalisation | stderr uniquement (stdout = flux JSON-RPC !) | Logs applicatifs standards |