# MCP (Model Context Protocol) : comment connecter un assistant à tes outils ?

> Comprendre MCP, brancher un premier serveur en lecture seule et diagnostiquer une connexion sans outil : rôles, capacités, autorisations et limites selon l'application.

Page : https://iatechnologie.com/mcp-model-context-protocol/
Mise à jour : 5 novembre 2026
Par Vincent Oliviero (https://iatechnologie.com/auteur/vincent-oliviero/), IA Technologie. Méthode et affiliation : https://iatechnologie.com/a-propos/#methode

MCP, pour **Model Context Protocol**, permet à une application d'IA de se connecter à un programme qui lui fournit des informations ou des actions. Pour un premier essai, le choix le plus simple est un serveur qui **lit** des documents : tu vois ce que l'assistant reçoit avant de lui confier un outil capable de modifier un fichier ou d'envoyer un message.

## MCP (Model Context Protocol), c'est quoi exactement ?

MCP définit la manière dont une application d’IA et un serveur échangent leurs demandes et leurs réponses. L’application utilise le modèle configuré et orchestre les étapes. Le serveur expose ses fonctions dans la limite des autorisations que tu accordes. La [spécification officielle de MCP](https://modelcontextprotocol.io/specification/2026-07-28) distingue trois acteurs :

| Acteur | Son rôle | Dans un exemple de recherche documentaire |
|---|---|---|
| **Hôte** | L'application d'IA avec laquelle tu échanges. Elle gère les connexions et présente les demandes d'autorisation. | Ton application d'assistance. |
| **Client MCP** | Le composant de l'hôte qui communique avec un serveur précis. L'hôte crée une connexion pour chaque serveur. | La connexion que l'application ouvre vers le serveur de documentation. |
| **Serveur MCP** | Le programme qui expose des capacités à l'application. Il peut tourner sur ton ordinateur ou à distance. | Le service qui cherche et renvoie une page de documentation. |

Le serveur peut exposer trois types de capacités. Un **outil** exécute une fonction, par exemple rechercher une page ou créer une tâche. Une **ressource** fournit un contenu à lire, par exemple un fichier ou un enregistrement. Un **prompt** est un modèle de demande réutilisable. Un serveur peut proposer une partie seulement de ces capacités ; l'application hôte peut également choisir ce qu'elle affiche et utilise. [L'architecture officielle](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) détaille ces rôles et ces primitives.

Cette distinction évite une confusion fréquente : un outil de recherche peut être **en lecture seule** même s'il est classé parmi les « outils ». Pour connaître les droits d’un outil, lis sa fonction et ses autorisations. Une recherche consulte un service. La création d’une tâche ou la suppression d’un fichier le modifie.

## Premier branchement MCP : lire avant d'écrire

Le [serveur MCP public de la documentation OpenAI](https://developers.openai.com/learn/docs-mcp) offre un exemple borné : il cherche et lit des pages de documentation. Il sert uniquement à consulter la documentation développeur. Si tu utilises **Codex en ligne de commande ou dans son extension IDE**, sa documentation propose ces commandes pour enregistrer puis vérifier la configuration :

```bash
codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp
codex mcp list
```

La seconde commande confirme que le serveur est enregistré. Vérifie ensuite une recherche depuis l’assistant. Demande ensuite à l'assistant : « Consulte la documentation officielle sur les outils de l'API Responses et donne-moi le titre et l'URL de la page utilisée. » Tu dois pouvoir ouvrir cette URL et confronter sa réponse à la source. Si l'assistant répond sans consulter le serveur, demande-lui explicitement de l'utiliser et vérifie que l'intégration est activée dans la surface où tu travailles. Ce parcours suit la procédure documentée par OpenAI.

Ce serveur sert à lire une documentation précise. Pour tes fichiers, ton calendrier ou un outil métier, il faut choisir un autre serveur et contrôler ses droits à part. Suis la page MCP de **l’application que tu utilises** pour savoir où déclarer le serveur et quels types de connexion elle accepte.

## Ce que change ton application

La compatibilité MCP se vérifie sur trois points concrets : le **transport** accepté, les **capacités** rendues visibles et les **autorisations** proposées. La documentation du protocole décrit un serveur local lancé par l'application via `stdio` et un serveur distant joint par **Streamable HTTP**. Dans ce dernier transport, les événements envoyés par le serveur peuvent servir au flux ; une ancienne mention de « SSE » ne suffit pas à établir qu'une configuration actuelle est compatible. [Voir l'architecture versionnée](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture).

Un client peut gérer les outils sans afficher toutes les ressources ou tous les prompts. Il peut demander une validation avant un appel, appliquer une liste d'outils autorisés, ou présenter une autre interface. Même avec le même serveur, le résultat visible dépend donc de l'application et parfois de son mode de travail. Consulte **sa** documentation et celle du serveur au lieu de te fier à une liste générale de clients « compatibles MCP ».

Si ton objectif est de faire travailler un agent de code, le [guide des agents IA pour coder](/agents-ia-code-modeles-ia-gratuits/) aide à choisir l'application. Si tu veux voir ce que l'ajout d'un serveur change réellement dans un cas spécialisé, [Reverse Engineer Anything](/reverse-engineer-anything/) décrit un serveur MCP qui relie un agent à des outils de rétro-ingénierie et le distingue de son skill, qui apporte des instructions. Un skill peut guider l'agent ; il n'ouvre pas, à lui seul, l'accès qu'offre un serveur. Le [glossaire IA](/glossaire-ia/#mcp) résume aussi la différence entre agent et MCP.

## Avant d'autoriser un serveur qui écrit

Après le premier essai en lecture, prends un cas concret : tu veux que l'assistant crée une tâche dans ton gestionnaire de projet. Avant de le connecter, vérifie ces quatre éléments dans la documentation du serveur et dans l'écran d'autorisation de ton application :

1. **Origine et portée.** Qui publie le serveur ? S'agit-il d'un service distant ou d'un programme lancé sur ton ordinateur ? Quels espaces de travail, dossiers ou projets pourra-t-il atteindre ?
2. **Compte et droits.** Avec quel compte se connecte-t-il ? Peut-il seulement lire les tâches, en créer, les modifier ou les supprimer ? Accorde le droit minimal utile à ton essai.
3. **Données échangées.** Quels éléments de la conversation et quels résultats d'outil quittent ton application ? Un serveur local peut lire un fichier local, mais le texte retourné à l'assistant peut ensuite être transmis au fournisseur du modèle selon le fonctionnement de l'application. Vérifie ses règles de données avant d'utiliser un document sensible.
4. **Validation de l'action.** L'application te montre-t-elle l'opération et sa cible avant exécution ? Demande une création de tâche sans conséquence, examine le résultat dans le service, puis élargis seulement si ce niveau de contrôle te convient.

La [spécification MCP](https://modelcontextprotocol.io/specification/2026-07-28) pose des principes de consentement et de contrôle de l'utilisateur, mais précise que le protocole ne les fait pas respecter seul. L'application et le serveur doivent les mettre en œuvre. N'accorde pas un accès en écriture à tout un dossier ou tout un espace de travail pour une simple consultation.

## Serveur connecté, mais aucun outil : où chercher ?

« Connecté » peut vouloir dire que l'application voit le serveur, sans garantir qu'il publie un outil utilisable. Le diagnostic le plus court consiste à distinguer **ce que publie le serveur** de **ce qu'affiche l'application**.

1. **Lis la documentation du serveur.** Annonce-t-elle des outils, des ressources, des prompts, ou une combinaison ? Un serveur de ressources sans outil peut fonctionner comme prévu.
2. **Compare la liste réelle.** Si des outils sont promis, un outil de diagnostic comme le [MCP Inspector officiel](https://modelcontextprotocol.io/docs/2026-07-28/tools/inspector) permet d'interroger le serveur et d'afficher sa réponse à `tools/list`. Suis sa documentation pour le transport et l'authentification de ton serveur ; ne colle pas de jeton dans un outil ou une page dont tu ne connais pas la provenance.
3. **Si Inspector voit les outils et pas ton application**, vérifie que le serveur est activé dans la bonne session, que ses outils sont autorisés dans ce mode, puis reconnecte l'application. Contrôle la prise en charge du transport et de la version indiquée par les deux documentations.
4. **Si Inspector ne voit aucun outil alors que le serveur en promet**, vérifie le compte connecté, les droits d'accès, la configuration du serveur et ses journaux. Une session authentifiée peut n'avoir accès à aucun projet ou à aucune capacité. Ne modifie pas une permission au hasard pour faire apparaître la liste.

Enfin, si **les outils sont visibles mais jamais utilisés**, le problème est différent : formule une demande qui nécessite clairement l'un d'eux, puis regarde si l'application réclame une validation. Le [guide de dépannage du SDK GitHub Copilot](https://docs.github.com/fr/copilot/how-tos/copilot-sdk/troubleshooting/mcp-debugging) documente cette différence de symptômes ; ses paramètres de configuration ne s'appliquent pas automatiquement aux autres clients.

Pour décider de ton prochain serveur, pars de la tâche : quelle information faut-il lire, quelle action faut-il éventuellement lancer, et quel est le droit minimal pour y parvenir ? Si la lecture suffit, garde cette limite. Si une action est nécessaire, exige un résultat que tu peux vérifier dans le service concerné avant d'étendre l'accès.