Origine de MCP et problème résolu
Anthropic a ouvert Model Context Protocol le 25 novembre 2024 afin de remplacer des intégrations spécifiques par une méthode ouverte reliant les assistants d'IA aux contenus, outils métier et environnements de développement. [1]
MCP ne remplace ni les bases de données ni les API REST. Un serveur MCP se place généralement au-dessus d'un système existant et expose ses capacités à un hôte d'IA compatible. [1][4]
Ce que MCP standardise, et ce qu'il ne standardise pas
MCP standardise la découverte et l'appel des tools, l'exposition des resources et les modèles de prompts réutilisables. Un hôte n'a donc pas besoin de connaître chaque API privée. [4][5][6][7]
La logique métier, le modèle de données et les politiques d'autorisation de l'entreprise restent à la charge de l'implémentation. [5][8]
Architecture pratique : hôte, client et serveur
| Élément | Rôle |
|---|---|
| Hôte | Application d'IA qui coordonne le modèle, l'utilisateur et les connexions MCP. |
| Client MCP | Couche de communication du protocole pour un serveur donné. |
| Serveur MCP | Expose des capacités et les relie aux données ou systèmes externes. |
| Tools | Actions invoquées par le modèle. |
| Resources | Données et contexte identifiés par URI. |
| Prompts | Modèles de prompts réutilisables. |
L'architecture MCP classique sépare hôte, client et serveur. L'hôte est l'application d'IA, le client implémente le protocole et le serveur expose données et opérations. La version actuelle conserve cette séparation tout en supprimant l'obligation de conserver un état HTTP entre les requêtes. [15][2]
Un hôte peut se connecter à plusieurs serveurs MCP, par exemple GitHub, un système de tickets et une base de connaissances interne. [12][15]
Tools, resources et prompts : les primitives principales
Les `tools` sont des actions que le modèle peut invoquer. La spécification décrit leur nom, leur description et leur schéma d'entrée. [5]
Les `resources` exposent des données identifiées par URI. Les `prompts` exposent des modèles de prompts réutilisables. [6][7]
STDIO, Streamable HTTP et l'ancien transport SSE
| Transport | Usage typique |
|---|---|
| STDIO | Processus local, CLI, IDE, outils de développement. |
| Streamable HTTP | Serveur distant, SaaS, infrastructure de production. |
| HTTP+SSE | Ancien transport HTTP, déprécié depuis 2026-07-28. |
STDIO convient aux serveurs locaux lancés comme processus. Streamable HTTP est destiné aux déploiements distants. [4][2]
Depuis `2026-07-28`, le cœur distant est sans état. Legacy HTTP+SSE est officiellement déprécié avec au moins douze mois de transition. [2]
À quoi ressemble un appel de tool aujourd'hui
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {"q": "invoice 2026"}
}
}Depuis `2026-07-28`, ni l'échange `initialize` ni `Mcp-Session-Id` ne sont obligatoires. Chaque requête peut porter version, informations client et capacités ; `server/discover` est optionnel. [2]
Avec Streamable HTTP, `Mcp-Method` et `Mcp-Name` facilitent routage, filtrage et mesure sans parser tout le corps JSON. [2]
Exemple concret : un agent connecté à un système de tickets
Un serveur MCP peut exposer `search_tickets`, `get_ticket` et `update_ticket` comme tools, la documentation comme resources et un prompt d'analyse d'incident. L'hôte découvre le catalogue, le modèle choisit l'action et le serveur appelle l'API interne. [5][6][7]
Le même serveur peut ensuite servir plusieurs hôtes compatibles sans réécrire l'intégration. [4][12]
Autorisation : OAuth 2.1, Bearer tokens et Client ID Metadata Documents
Pour HTTP, l'autorisation MCP s'appuie sur OAuth 2.1 et les mécanismes de découverte. Les jetons d'accès sont envoyés dans `Authorization: Bearer` et ne doivent jamais apparaître dans la query string. [8]
La validation de l'audience et PKCE sont des protections importantes. Dynamic Client Registration est désormais déprécié au profit des Client ID Metadata Documents. [2][8]
Sécurité : MCP ne signifie pas confiance totale
Les serveurs doivent valider les entrées, appliquer les droits, limiter les appels et assainir les résultats. Les clients devraient demander confirmation pour les actions sensibles, afficher les arguments, appliquer des timeouts et journaliser les appels. [5]
Le moindre privilège est essentiel. Un serveur de lecture ne devrait pas posséder des droits d'effacement en production. [5][8][13]
MCP Apps : lorsqu'un tool a besoin d'une interface
MCP Apps est une extension officielle permettant de retourner formulaires, tableaux de bord ou visualisations interactives. Un tool référence une resource `ui://` rendue dans un iframe sandboxé par l'hôte. [9]
Les échanges restent structurés et auditables, et l'hôte peut demander le consentement avant un appel déclenché depuis l'interface. [9]
Tasks : opérations longues sans connexion persistante
MCP Tasks permet au serveur de retourner un identifiant durable au lieu de bloquer une connexion pendant une opération longue. Le client interroge ensuite l'état et récupère le résultat. [10]
CI, batch, déploiements, files externes et validations humaines sont des cas d'usage naturels. [10][2]
Adoption : Anthropic, OpenAI, GitHub et outils de développement
OpenAI prend en charge les serveurs MCP distants dans Responses API depuis mai 2025 et a rejoint le comité de pilotage MCP. [11]
GitHub Copilot prend en charge MCP dans les IDE, CLI, l'application Copilot et cloud agent, avec registry et contrôles d'entreprise. [12][13][14]
MCP face aux API REST et au function calling
REST décrit une interface générale de système ; function calling décrit l'appel de fonctions par un modèle donné. MCP ajoute une couche commune de découverte, schémas et communication entre hôte d'IA et serveur d'outils. [4][5]
Pour quelques fonctions privées utilisées par un seul backend, MCP peut être superflu. Pour plusieurs hôtes ou une intégration distribuée comme produit, il devient nettement plus utile. [4][11][12]
Checklist d'un serveur MCP de production
Commencez par peu de tools, bien nommés et décrits, avec schémas validés et droits minimaux. [5][8]
Pour un serveur distant, ciblez Streamable HTTP actuel, mettez en place autorisation, métriques, rate limiting et tracing, et gérez explicitement la compatibilité. [2][8]
- Cibler la spécification `2026-07-28`.
- Réduire la surface des tools et les droits.
- Valider tous les arguments et résultats.
- Exiger une confirmation pour les opérations sensibles.
- Pour HTTP, implémenter correctement OAuth et la validation audience.
- Utiliser rate limiting, timeouts, audit et tracing.
- Ne jamais transmettre de secrets inutiles.
- Tester la compatibilité des hôtes et les erreurs.
Les changements de 2026 et la direction du protocole
`2026-07-28` a introduit le cœur sans état, supprimé handshake et sessions, ajouté cache des listes, routage par en-têtes, extensions formelles et renforcement de l'autorisation. Roots, Sampling et Logging sont dépréciés pour les nouvelles implémentations. [2]
La roadmap d'août 2026 vise messagerie agentique, webhooks, événements, unification HTTP, identité des agents, sécurité d'entreprise et meilleure expérience SDK. Ce sont des orientations, pas toutes des fonctions déjà disponibles. [3]
