Le Model Context Protocol (MCP) est un standard ouvert qui definit comment un agent IA se connecte a des outils externes. Chaque outil -- Gmail, Slack, Jira, un ERP interne -- est encapsule dans un serveur MCP qui expose ses capacites de maniere uniforme. L'agent decouvre les outils disponibles et les utilise sans integration sur mesure.

Le probleme des integrations sur mesure

Avant MCP, connecter un agent IA a un outil externe demandait un travail d'integration specifique pour chaque service. Il fallait ecrire du code pour chaque API, gerer l'authentification, transformer les formats de donnees, traiter les erreurs. Pour N outils, il fallait N integrations.

La multiplication des connecteurs

Chaque fournisseur d'IA a construit ses propres connecteurs. OpenAI a ses plugins, Google a ses extensions, chaque framework agent a ses propres abstractions. Le resultat : un ecosysteme fragmente ou chaque connecteur est incompatible avec les autres.

Pour une entreprise qui utilise 10 outils, cela signifiait 10 integrations custom. Et quand l'API d'un outil changeait, il fallait mettre a jour le connecteur, retester, redeployer. La maintenance devenait un gouffre.

Le probleme de la decouverte

Avec des integrations sur mesure, l'agent ne peut utiliser que les outils qu'on a explicitement codes pour lui. Ajouter un nouvel outil necessite du developpement, des tests et un deploiement. Il n'y a aucun mecanisme standard pour qu'un agent decouvre de nouveaux outils a la volee.

Comment fonctionne le protocole MCP

MCP resout ces problemes en introduisant une interface standard entre les agents IA et les outils externes. Le principe est simple : chaque outil est encapsule dans un serveur MCP qui repond a un protocole commun.

L'architecture client-serveur

Un serveur MCP est un processus independant qui expose des outils (tools). Chaque outil est une fonction avec un nom, une description, des parametres types et un format de retour. Le serveur repond a deux types de requetes :

list_tools -- retourne la liste des outils disponibles avec leurs descriptions et schemas de parametres
call_tool -- execute un outil specifique avec les parametres fournis et retourne le resultat

L'agent IA (le client MCP) se connecte au serveur, decouvre les outils disponibles via list_tools, puis appelle call_tool quand il decide d'utiliser un outil.

Un serveur par service

Chaque service externe est un serveur MCP independant. Un serveur Gmail MCP expose des outils comme search_emails, send_email, get_unread. Un serveur Jira MCP expose create_issue, update_issue, search_issues. Chaque serveur est une application autonome de 200 a 400 lignes de code.

Cette granularite est deliberee. Un serveur MCP est simple a comprendre, simple a tester, simple a deployer. Il ne depend d'aucun autre serveur. Si le serveur Jira MCP tombe, le serveur Gmail MCP continue de fonctionner.

Le transport

MCP supporte deux modes de transport :

SSE (Server-Sent Events) -- le serveur MCP tourne comme un service HTTP. Le client se connecte et maintient une connexion persistante.
stdio -- le serveur MCP est lance comme un processus enfant. La communication se fait via l'entree/sortie standard. Ce mode est pratique pour le developpement et les deploiements simples.

Les deux modes utilisent le meme protocole JSON-RPC sous-jacent. Le code de l'agent ne change pas selon le mode de transport.

Exemples concrets de serveurs MCP

Serveur Gmail MCP

Un serveur Gmail MCP typique expose ces outils :

search_emails -- recherche dans les emails avec la syntaxe Gmail (from:, to:, subject:, is:unread)
get_unread -- retourne les emails non lus avec un resume
send_email -- envoie un email (to, subject, body, cc, bcc)
create_draft -- cree un brouillon sans l'envoyer

Chaque outil recoit les parametres en JSON et retourne le resultat en JSON. L'authentification se fait via OAuth2 : le serveur MCP detient les tokens de l'utilisateur et gere le rafraichissement automatiquement.

Serveur Jira MCP

search_issues -- recherche via JQL (Jira Query Language)
create_issue -- cree un ticket avec projet, type, resume, description, assignee
update_issue -- modifie un ticket existant (statut, assignee, priorite)
add_comment -- ajoute un commentaire a un ticket

Serveur Calendar MCP

list_events -- liste les evenements sur une periode donnee
create_event -- cree un evenement avec titre, date, duree, participants
find_free_slots -- trouve les creneaux libres entre plusieurs participants

La coherence du protocole est frappante. Pour l'agent, appeler search_emails ou search_issues suit exactement le meme mecanisme. C'est cette uniformite qui rend le systeme extensible.

L'ecosysteme open source

L'un des avantages majeurs de MCP est son ecosysteme ouvert. Des centaines de serveurs MCP sont disponibles en open source, couvrant la plupart des outils professionnels courants.

Des serveurs communautaires

La communaute a deja produit des serveurs MCP pour GitHub, GitLab, Notion, Confluence, Google Drive, Salesforce, HubSpot, PostgreSQL, MongoDB, et des dizaines d'autres services. Certains sont maintenus par les editeurs eux-memes.

Pour une entreprise, cela signifie que la plupart des integrations sont deja disponibles. Il suffit de deployer le serveur MCP correspondant et de le connecter a l'agent.

La standardisation accelere l'innovation

Parce que le protocole est standard, un serveur MCP ecrit par un developpeur independant fonctionne avec n'importe quel agent compatible MCP. Il n'y a pas de verrouillage fournisseur. Vous pouvez changer d'agent IA sans reecrire vos integrations.

Construire un serveur MCP custom

Pour les outils internes -- un ERP maison, un CRM specifique, une base de donnees proprietaire -- vous pouvez construire votre propre serveur MCP. La structure est remarquablement simple.

Avec FastMCP en Python

FastMCP est un framework Python qui reduit la creation d'un serveur MCP a quelques lignes :

from fastmcp import FastMCP

mcp = FastMCP("Mon ERP")

@mcp.tool()
def search_clients(query: str, limit: int = 10) -> list[dict]:
    """Recherche des clients dans l'ERP par nom ou reference."""
    # Votre logique metier ici
    return erp_db.search(query, limit=limit)

@mcp.tool()
def get_invoice(invoice_id: str) -> dict:
    """Recupere une facture par son identifiant."""
    return erp_db.get_invoice(invoice_id)

En quelques dizaines de lignes, vous avez un serveur MCP fonctionnel que n'importe quel agent peut utiliser. Les types sont automatiquement convertis en schemas JSON pour la decouverte d'outils.

Les bonnes pratiques

Quelques principes pour un serveur MCP de qualite :

Un outil par action -- search_clients et get_client sont deux outils distincts, pas un seul outil avec un parametre mode
Descriptions claires -- la description de chaque outil est lue par le modele de langage. Elle doit etre precise et informative
Parametres types -- utilisez les types Python et Pydantic pour valider les entrees
Gestion d'erreurs -- retournez des messages d'erreur explicites, pas des stack traces
Idempotence -- un outil appele deux fois avec les memes parametres doit produire le meme resultat (sauf pour les actions d'ecriture)

L'architecture MCP-first

Une architecture MCP-first signifie que toutes les connexions externes passent par des serveurs MCP, sans exception. L'agent ne parle jamais directement a une API. Chaque service est une brique independante et interchangeable.

Le pool MCP

Un agent d'entreprise se connecte a plusieurs serveurs MCP simultanement. Le pool MCP gere ces connexions : decouverte des outils, routage des appels, gestion des deconnexions, reconnexion automatique. L'agent voit l'ensemble des outils comme un catalogue unifie.

Ajout dynamique

Ajouter un nouvel outil a l'agent, c'est deployer un nouveau serveur MCP et l'enregistrer dans le pool. Aucune modification du code de l'agent n'est necessaire. L'agent decouvre automatiquement les nouveaux outils et peut les utiliser dans sa prochaine interaction.

Isolation et securite

Chaque serveur MCP est isole. Les credentials Gmail ne sont pas accessibles par le serveur Jira. Un bug dans un serveur n'affecte pas les autres. Cette isolation est un avantage de securite majeur par rapport aux architectures monolithiques ou toutes les integrations partagent le meme processus.

L'approche Wardian

Wardian a fait le choix d'une architecture MCP-first des sa conception. Chaque integration est un serveur MCP independant, deploye dans le reseau du client. L'agent se connecte a ces serveurs via un pool MCP manage qui gere la decouverte, le routage et la resilience.

Pour les deploiements SaaS ou les serveurs MCP sont derriere le firewall du client, un composant leger -- le Wardian Gateway -- ouvre une connexion sortante vers le cloud. Le pool MCP route les appels a travers ce tunnel de maniere transparente. L'agent ne fait aucune difference entre un serveur MCP local et un serveur MCP distant.

Le resultat : une architecture extensible, securisee et sans verrouillage fournisseur. Vos serveurs MCP vous appartiennent. Ils fonctionnent avec Wardian aujourd'hui et fonctionneront avec n'importe quel agent compatible MCP demain.