Qu'est-ce qu'un serveur MCP ?

MCP standardise les connexions aux outils et au contexte externes. Pensez à une interface partagée plutôt qu'à une nouvelle intelligence à l'intérieur du serveur.

Vous pouvez suivre ce cours sans compte ni programmation. Les exemples utilisent des données synthétiques et les résultats de l’IA doivent être vérifiés.

Comment ça marche, étape par étape

Hôte, client et serveur

MCP est un protocole connectant les applications d'IA à des capacités externes. L'hôte fournit l'expérience, le client gère la connexion et le serveur expose des outils, des ressources ou des invites en fonction de la prise en charge. Les outils exécutent des opérations ; les ressources fournissent un contenu adressable ; les invites fournissent des modèles. Tous les serveurs n'implémentent pas les trois. Le transport transporte les messages, l'authentification identifie les appelants et l'autorisation contrôle l'accès. Vérifiez la révision du protocole et les extensions prises en charge aux deux extrémités. La compatibilité ne peut pas être déduite de la seule étiquette « MCP ».

Le modèle propose, l'outil exécute

L'appel d'outil produit une demande d'appel avec un nom et des arguments. L'application valide le schéma, les autorisations et les limites avant exécution. Le résultat revient au contexte pour l'étape suivante. Par exemple, get_product_stock prend un SKU et renvoie une quantité ; sa description doit expliquer qu'il ne réserve pas de produits. Distinguez les résultats vides, les erreurs de validation, les accès manquants et les délais d’attente. Un JSON valide ne prouve pas que les arguments sont corrects ou que l'action est autorisée. Pour les effets externes, envisagez également une exécution en double.

Vérifier l'accès avant utilisation

Les autorisations doivent être appliquées par les serveurs et la couche de données. Ne laissez pas le modèle décider si un utilisateur peut voir un document. Filtrez les sources avant qu'elles n'entrent dans le contexte, et non après avoir généré la réponse. Utilisez des informations d'identification à accès minimal, gardez-les à l'écart des invites, des captures d'écran et du code du navigateur, et faites pivoter les clés exposées. Une liste blanche de domaines de widgets ne remplace pas l'authentification API. L'authentification vous identifie ; l’autorisation détermine les opérations et les données que vous pouvez utiliser. Test d'accès refusé également.

Le schéma explicatif

Suivez les flèches pleines pour le flux principal. Les flèches bleues en pointillés fournissent des données ou un contexte ; les flèches roses en pointillés affichent des commentaires ou des résultats renvoyés. Les couleurs et les formes distinguent les modèles, les magasins, les décisions et les sorties. Sur un petit écran, faites défiler horizontalement pour suivre le schéma complet.

Un exemple complet

Un serveur peut proposer get_product_stock, une ressource manuelle et une invite d'assistance. L'agent ne les reçoit pas automatiquement : le client et le serveur doivent les prendre en charge.

Essayez-le vous-même

1. Dessinez une connexion d'agent à un catalogue et classez les trois primitives.
2. Enregistrez l’entrée, la source et le résultat attendu avant d’exécuter l’expérience. Utilisez uniquement les données fictives de l'exemple.
3. Suivez les étapes du diagramme. À chaque étape, enregistrez les informations reçues et produites ; ne confondez pas le résultat intermédiaire avec le résultat final.
4. Répétez après avoir supprimé les informations nécessaires ou rendu la saisie ambiguë. Vérifiez si le système clarifie, arrête ou invente une réponse.
5. Comparez avec la solution expliquée. Conservez la configuration, la date, le résultat et une explication des différences. Changez une chose et retestez.

Une solution expliquée

Identifiez l'hôte, le client et le serveur et distinguez une opération du contenu et d'un modèle. Un exercice réussi vous permet de montrer le lien entre les contributions, les étapes et les résultats. Lorsqu’une information manque, une réponse prudente est plus utile que des détails inventés. Comparez bien plus que le style : vérifiez également les conditions, les sources et les opérations.

Quand cette approche est utile et quelles sont ses limites

MCP ne remplace pas la logique d’autorisation de service externe. Choisissez cette approche lorsqu’elle améliore un besoin mesuré. Gardez une base de référence simple et comparez les résultats en utilisant des entrées identiques. Un exemple réussi n’établit pas la fiabilité dans toutes les situations.

Vérifiez vos connaissances

Un serveur doté d’outils propose-t-il automatiquement des ressources et des invites ?

Non. Les fonctionnalités sont facultatives et doivent être découvertes et vérifiées.

Qui exécute un appel proposé par le modèle ?

L'application ou le service hôte après validation. Le modèle n'obtient pas automatiquement un accès illimité.

Quel résultat cet exercice devrait-il produire ?

Identifiez l'hôte, le client et le serveur et distinguez une opération du contenu et d'un modèle.

Les mots à retenir

• Serveur MCP: Un service exposant des capacités via Model Context Protocol.
• Appel d'outil: Une demande structurée pour utiliser une capacité externe.
• Autoriser / Autorisation: Vérification du droit d'accès à une opération ou une ressource.

Sources et votre prochaine étape

• Model Context Protocol — Spécification
• LangGraph — Flux de travail et agents
• OWASP — Injection de prompt

Pour préparer : A01 — Anatomie d'un agent IA