Le protocole MCP expliqué : comment vos agents IA parlent à vos outils en 2026

Qu'est-ce que le protocole MCP ?

Le Model Context Protocol (MCP) est un protocole standard ouvert, initialement développé par Anthropic et aujourd'hui adopté par l'ensemble de l'écosystème des agents IA. Son objectif : définir une interface universelle qui permet à un modèle de langage (LLM) de communiquer avec des outils externes de manière structurée, cohérente et sécurisée.

Avant MCP, chaque intégration était une aventure. Vous vouliez que votre agent IA puisse lire des données depuis Notion, poster sur Slack, puis déployer un fichier sur Netlify ? Il fallait écrire trois intégrations custom distinctes, gérer trois formats de réponse différents, et maintenir trois fois plus de code. Le moindre changement dans l'API d'un outil pouvait casser toute la chaîne.

MCP résout ce problème fondamental en introduisant une couche d'abstraction standardisée : un agent parle MCP, et c'est le serveur MCP de chaque outil qui traduit vers l'API native. L'agent n'a plus à connaître les spécificités de chaque outil — il pose une question en MCP, il reçoit une réponse en MCP.

La structure technique de base

MCP repose sur une architecture client-serveur simple :

Le client MCP, c'est l'agent lui-même — ou plus précisément, le runtime qui exécute l'agent. Il déclare quels outils sont disponibles (sous forme de "tools" avec leurs paramètres) et initie les appels.

Le serveur MCP est un processus intermédiaire qui expose les capacités d'un outil (lire des métriques, créer un fichier, envoyer un message) sous une interface standardisée. Il traduit les appels MCP en requêtes natives vers l'API cible, puis retourne le résultat dans un format que le LLM peut lire directement.

La communication entre client et serveur utilise JSON-RPC 2.0 via stdio ou SSE — une spécification légère, bien documentée, et implémentable dans n'importe quel langage.

Pourquoi MCP change fondamentalement la façon de construire des agents

Pour comprendre l'impact de MCP, il faut revenir sur le problème qu'il résout. La vraie puissance d'un agent IA n'est pas dans sa capacité à raisonner en isolation — c'est dans sa capacité à agir sur le monde réel : lire un fichier, interroger une base de données, appeler un webhook, publier un contenu.

Sans standard, chaque "capacité d'action" est une intégration artisanale. Le développeur écrit du code custom pour chaque outil, documente les paramètres pour que le LLM comprenne comment les appeler, gère les cas d'erreur, et recommence pour le prochain outil. À l'échelle d'un système avec une douzaine d'outils différents, c'est des centaines de lignes de glue code à maintenir.

Persistance du contexte entre les appels

MCP va plus loin que la simple normalisation des appels. Il définit aussi comment le contexte est maintenu entre plusieurs interactions avec un outil. Un agent peut ouvrir une "session" avec un serveur MCP, effectuer plusieurs opérations successives, et le serveur maintient l'état entre les appels.

C'est particulièrement puissant pour des workflows qui requièrent plusieurs étapes : lire un fichier, le modifier, le sauvegarder, puis vérifier la modification — tout ça dans la même session MCP, sans perdre le contexte à chaque appel.

Observabilité et traçabilité

Chaque appel MCP est structuré et identifiable. Dans un système multi-agents complexe, cela signifie qu'on peut tracer exactement quel agent a appelé quel outil, avec quels paramètres, et quelle réponse a été retournée. C'est un changement majeur par rapport aux appels API custom, souvent opaques et difficiles à déboguer.

MCP vs API directe : comparaison pratique

La question qu'on nous pose souvent : "Pourquoi ne pas appeler les APIs directement ?" C'est une question légitime. Les APIs directes fonctionnent, sont documentées, et ne nécessitent pas d'apprendre un nouveau protocole. Voici la comparaison honnête.

La conclusion est nuancée : pour un agent unique qui utilise 1-2 outils stables, l'API directe peut être suffisante. Mais dès qu'on parle d'un système multi-agents avec plusieurs outils, ou d'une architecture destinée à évoluer dans le temps, MCP devient le meilleur choix — en termes de maintenabilité et de vélocité.

// === APPROCHE API DIRECTE ===
// Code custom à écrire et maintenir pour chaque outil
const response = await fetch(
  `https://plausible.io/api/v1/stats/aggregate?site_id=cofounder.bz&period=7d`,
  { headers: { 'Authorization': `Bearer ${API_KEY}` } }
);
const data = await response.json();
// Parsing custom, gestion erreurs custom, format de réponse custom...

// === APPROCHE MCP ===
// L'agent appelle le serveur MCP Plausible — même résultat, zero glue code
{
  "tool": "plausible_get_stats",
  "arguments": {
    "site_id": "cofounder.bz",
    "period": "7d",
    "metrics": ["visitors", "bounce_rate", "visit_duration"]
  }
}
// Réponse normalisée, contexte maintenu, loggable automatiquement

Comment CoFounder utilise MCP avec ses 11 agents

Chez CoFounder, MCP n'est pas une expérimentation — c'est l'infrastructure de base sur laquelle tourne l'intégralité du système depuis le Jour 1. Voici comment chaque agent en tire parti dans son cycle d'exécution de 48 heures.

Clara et Victor — Métriques Plausible en temps réel

Clara (stratégie) et Victor (dashboard) utilisent le serveur MCP Plausible pour accéder aux métriques de trafic à chaque cycle. L'appel est trivial : demander les visiteurs uniques, le taux de rebond, la durée de visite, et la répartition par source sur les 7 derniers jours. La réponse est directement utilisable dans leur raisonnement sans parsing supplémentaire.

Ce qui serait impossible sans MCP : orchestrer deux agents distincts qui lisent les mêmes données de manière cohérente, sans qu'aucun d'eux n'ait à gérer le token d'API Plausible ou le format de réponse brut.

Lucas — Déploiement Netlify autonome

Lucas (déploiement) est l'agent qui illustre le mieux la puissance de MCP en production. À chaque cycle, il génère un ZIP du site, le déploie via le serveur MCP Netlify, vérifie le statut du déploiement, et confirme le build number dans agent-log.md. L'ensemble de ce workflow — qui implique plusieurs appels séquentiels — est géré via MCP avec une cohérence de contexte garantie entre les étapes.

Sans MCP, ce workflow aurait nécessité du code custom pour gérer la session, les états intermédiaires, et la récupération en cas d'erreur. Avec MCP, c'est le protocole qui s'en charge.

Tous les agents — Lecture/écriture dans agent-log.md

Le cœur de notre architecture est le pattern Blackboard : un fichier markdown partagé (agent-log.md) que tous les agents lisent et écrivent à chaque cycle. L'accès à ce fichier passe par un serveur MCP fichiers — ce qui garantit une interface cohérente pour tous les agents, quelle que soit leur spécialité.

L'ajout de nouveaux outils : un cas concret

Un exemple récent illustre bien l'avantage MCP : l'intégration du tracking Plausible côté client a nécessité exactement deux lignes de configuration côté agent pour qu'il puisse accéder aux nouvelles métriques. Aucun code de parsing. Aucune gestion d'erreur custom. Le serveur MCP Plausible existant gérait déjà tout ça.

C'est ça, la promesse de MCP tenue en pratique : la vélocité d'ajout d'un nouvel outil est proportionnelle à l'existence d'un serveur MCP, pas à la complexité de l'API native.

Cas d'usage pratiques et état de l'écosystème en 2026

L'écosystème MCP a connu une croissance remarquable depuis son introduction. En 2026, les serveurs MCP disponibles couvrent la majorité des outils du quotidien technique.

Outils disponibles via MCP aujourd'hui

Parmi les serveurs MCP les plus utilisés actuellement : GitHub (création de PR, lecture de code, gestion d'issues), Notion (pages, bases de données, blocs), Slack (envoi de messages, lecture de canaux), Google Drive (fichiers, documents), Netlify (déploiements, fonctions, DNS), Plausible / PostHog (analytics), des connecteurs SQL génériques, des systèmes de fichiers locaux, et des navigateurs headless pour le web scraping.

Des registres publics (comme celui de Cowork) recensent des centaines de serveurs MCP disponibles, avec de nouvelles intégrations chaque semaine portées par la communauté open source.

MCP dans les frameworks multi-agents

L'adoption de MCP par les frameworks est déjà bien avancée. CrewAI supporte MCP nativement en first-class depuis mi-2025 — les agents CrewAI peuvent consommer des serveurs MCP directement sans wrapper custom. Claude Desktop et Claude Code (Anthropic) utilisent MCP comme protocole d'intégration principal. L'OpenAI Agents SDK a annoncé une compatibilité partielle, et l'écosystème LangChain dispose de connecteurs MCP communautaires.

Créer ses propres serveurs MCP

L'un des cas d'usage les plus puissants, et souvent sous-estimé : créer des serveurs MCP custom pour des outils internes. Si votre entreprise dispose d'un CRM propriétaire, d'une base de données interne, ou d'un ERP, vous pouvez exposer ses capacités via un serveur MCP. N'importe quel agent compatible MCP peut alors l'utiliser sans modification.

La spécification est bien documentée sur le site officiel d'Anthropic. Implémenter un serveur MCP basique en Python ou TypeScript prend quelques heures pour un développeur familier avec les APIs REST.

# Structure de base d'un serveur MCP custom
from mcp.server import Server
from mcp.types import Tool, TextContent

app = Server("mon-outil-interne")

# Déclarer les outils disponibles
@app.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_data",
            description="Récupère des données depuis notre système interne",
            inputSchema={
                "type": "object",
                "properties": {
                    "query": { "type": "string" }
                }
            }
        )
    ]

# Implémenter la logique de chaque outil
@app.call_tool()
async def call_tool(name, arguments):
    if name == "get_data":
        result = mon_api_interne(arguments["query"])
        return [TextContent(type="text", text=str(result))]

Ce serveur MCP minimal est ensuite consommable par n'importe quel agent compatible — Claude, CrewAI, ou votre propre runtime. Le code de l'agent lui-même ne change pas.

Ce qu'on a appris en 14 jours d'utilisation intensive de MCP

Après 14 jours de build in public avec 11 agents qui utilisent MCP en production, voici les leçons honnêtes.

La documentation des outils disponibles côté agent est cruciale. MCP normalise les appels, mais le LLM a besoin de descriptions claires de ce que fait chaque outil et quand l'utiliser. Un serveur MCP mal documenté est aussi inutile qu'une API sans documentation.

Les erreurs côté serveur MCP sont traçables mais pas toujours explicites. Quand un serveur MCP retourne une erreur, elle est standardisée — c'est un progrès par rapport aux réponses d'erreur hétérogènes des APIs directes. Mais le diagnostic reste parfois laborieux, en particulier pour les timeouts sur des outils lents.

L'investissement initial en configuration est réel mais rentabilisé rapidement. Mettre en place les premiers serveurs MCP prend du temps. Mais à partir du 3ème ou 4ème outil intégré, la vélocité s'accélère significativement. Pour notre 11ème outil intégré, la mise en place a été quasi-instantanée.

MCP et le pattern Blackboard se complètent naturellement. Notre architecture repose sur deux piliers : MCP pour les interactions outils, et agent-log.md (pattern Blackboard) pour la coordination inter-agents. Les deux sont orthogonaux et se renforcent mutuellement. Vous pouvez retrouver l'architecture complète sur la page /architecture.