Model Context Protocol : Créer ton premier serveur MCP aujourd'hui

Le Model Context Protocol (MCP) est un standard ouvert qui donne aux modèles d'IA une façon universelle de se connecter à des outils externes, des sources de données et des services. Au lieu d'écrire du code d'intégration personnalisé pour chaque combinaison modèle-outil, tu écris un seul serveur MCP et chaque modèle compatible peut l'utiliser. Anthropic a créé MCP fin 2024, la Linux Foundation le gouverne désormais, et OpenAI, Google et le reste de l'écosystème IA agentique l'ont adopté. Voici tout ce que tu dois comprendre, construire et déployer avec MCP.

MCP en un coup d'œil

Si tu veux la version rapide avant de plonger dans 6 000 mots de détails, la voici.

Maintenant, décortiquons chacun de ces points, en commençant par ce qu'est réellement MCP et le problème qui l'a rendu nécessaire.

Qu'est-ce que le Model Context Protocol ?

Le Model Context Protocol est un protocole ouvert basé sur JSON-RPC qui standardise la façon dont les modèles IA découvrent et interagissent avec des outils et données externes. Pense-y comme HTTP pour les intégrations IA -- un langage commun que tout modèle et tout outil peut parler.

Tu as probablement entendu l'analogie USB-C, et elle est utile jusqu'à un certain point : avant USB-C, chaque appareil avait besoin de son propre câble. MCP fait la même chose pour l'IA, mais l'analogie le sous-estime. USB-C ne transporte que des données et de l'énergie. MCP transporte des définitions d'outils, des schémas d'accès aux données, des templates de prompts réutilisables, et permet même aux serveurs de demander des completions au modèle. C'est un protocole bien plus riche qu'une métaphore de câble ne le suggère.

Le problème M x N que MCP résout

Sans MCP, connecter M modèles à N outils nécessite M x N intégrations personnalisées. Supposons que tu supportes 5 LLMs (Claude, GPT-4, Gemini, Llama, Mistral) et que tu doives leur donner accès à 10 outils (GitHub, Postgres, Slack, Jira, etc.). Ça représente 50 couches d'intégration sur mesure, chacune avec sa propre authentification, gestion des erreurs et formatage des données.

Avec MCP, chaque modèle implémente le protocole client MCP une fois, et chaque outil implémente un serveur MCP une fois. C'est maintenant 5 + 10 = 15 implémentations au lieu de 50. Ajouter un nouveau modèle ? Il fonctionne immédiatement avec les 10 outils. Ajouter un nouvel outil ? Les 5 modèles peuvent l'utiliser.

Une brève histoire de MCP

Anthropic a publié MCP en open source en novembre 2024 avec des SDKs pour Python et TypeScript ainsi que des connecteurs pour Claude Desktop. L'adoption a été rapide. OpenAI a ajouté le support MCP à ChatGPT en mars 2025. Google a suivi pour Gemini en avril 2025. En décembre 2025, Anthropic a fait don de MCP à la nouvelle Agentic AI Foundation (AAIF) de la Linux Foundation, co-fondée avec Block et OpenAI, faisant de MCP un standard neutre vis-à-vis des vendeurs avec une gouvernance inter-industrie.

Ce que MCP N'EST PAS :

• Pas un modèle ni un framework IA (c'est un protocole, comme HTTP)
• Pas un remplaçant de LangChain ou LlamaIndex (ce sont des couches d'orchestration ; MCP se situe en dessous)
• Pas limité à Anthropic ou Claude (il est agnostique par design)
• Pas la même chose que le function calling (plus d'informations dans la section comparaison)

Comment fonctionne MCP ? Plongée dans l'architecture

MCP a trois rôles, et les confondre est l'erreur de débutant la plus courante. Clarifions la distinction.

Host, Client et Server -- Quelle est la différence ?

Voici un exemple concret : tu demandes à Claude Desktop de vérifier tes pull requests GitHub ouverts. Claude Desktop est le host. Son client MCP intégré ouvre une connexion au serveur MCP GitHub. Le serveur appelle l'API GitHub, récupère tes PRs et renvoie les résultats au client, qui les transmet au modèle.

Un seul host peut faire tourner plusieurs clients, chacun connecté à un serveur différent. C'est ainsi que Claude Desktop peut accéder simultanément à GitHub, ta base de données Postgres et Slack -- trois serveurs MCP séparés, trois connexions client séparées, un seul host.

Comment les messages circulent (JSON-RPC 2.0)

Toute communication MCP utilise JSON-RPC 2.0 -- un protocole requête/réponse léger. Voici à quoi ressemble un échange tools/list sur le réseau :

// Requête client : "Quels outils as-tu ?"
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

// Réponse serveur : un outil disponible
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Obtenir la météo actuelle pour une ville",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Le modèle lit ces définitions d'outils, décide quand les appeler en fonction de la requête de l'utilisateur, et le client envoie une requête tools/call au serveur avec les arguments appropriés.

Cycle de vie de la connexion

Chaque session MCP suit le même cycle de vie :

1. Initialisation -- le client envoie ses capacités, le serveur répond avec les siennes
2. Négociation des capacités -- les deux parties s'accordent sur les fonctionnalités supportées (outils, resources, prompts, sampling)
3. Prêt -- la connexion est active ; les requêtes circulent dans les deux sens
4. Requêtes/réponses -- tools/call, resources/read, etc.
5. Arrêt -- déconnexion propre

Cette négociation initiale assure la compatibilité ascendante. Si un serveur ajoute une nouvelle primitive, les anciens clients l'ignorent gracieusement au lieu de planter.

Primitives MCP : Outils, Resources, Prompts et Sampling

MCP définit quatre primitives, et comprendre qui contrôle chacune d'elles est la clé pour concevoir de bons serveurs MCP.

Outils (contrôlés par le modèle)

Les outils sont des fonctions que le modèle peut appeler. Le serveur les déclare avec un nom, une description et une définition de schéma d'entrée JSON. Le modèle lit ces définitions et, quand la requête d'un utilisateur le nécessite, décide d'invoquer l'outil.

// Le client envoie une requête tools/call
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "Paris" }
  }
}

Si tu as utilisé le function calling d'OpenAI, les outils te sembleront familiers -- mais ils sont standardisés pour chaque modèle compatible MCP.

Resources (contrôlées par l'application)

Les resources sont des endpoints de données en lecture seule. Contrairement aux outils, le modèle ne décide pas de récupérer une resource de lui-même -- l'application host ou l'utilisateur attache explicitement des resources au contexte de conversation. Pense-y comme des endpoints GET : postgres://mydb/users/schema, file://docs/api-reference.md.

Les resources supportent les abonnements via resources/subscribe, afin que le client puisse être notifié quand les données changent.

Prompts (contrôlés par l'utilisateur)

Les prompts sont des templates réutilisables qu'un serveur MCP expose. Un prompt code_review pourrait accepter un chemin de fichier et générer une demande de révision structurée. L'utilisateur (ou l'interface host) déclenche les prompts explicitement -- ils ne sont pas auto-invoqués par le modèle.

Sampling (initié par le serveur) -- Avancé

Voici la primitive que la plupart des guides ignorent. Le Sampling permet au serveur de demander au client de générer une completion en utilisant le LLM. Cela inverse le flux habituel : au lieu que le modèle appelle un outil, c'est l'outil qui appelle le modèle.

Pourquoi ? Les boucles agentiques. Imagine un serveur MCP qui traite des tickets de support. Il lit le ticket (une resource), utilise sampling/createMessage pour demander au modèle un résumé, puis utilise ce résumé pour router le ticket via un outil. Le serveur orchestre un workflow en plusieurs étapes en tirant parti de l'intelligence du modèle.

Le sampling est contrôlé par l'application host -- l'utilisateur doit l'approuver, et le host contrôle ce que le serveur peut demander. Cela empêche les boucles incontrôlées et maintient la supervision humaine.

Construire ton premier serveur MCP : Python et TypeScript côte à côte

Assez de théorie. Construisons un serveur MCP fonctionnel qui expose un outil get_weather. Je montrerai Python et TypeScript pour que tu puisses comparer l'expérience développeur et choisir la stack qui convient à ton projet.

Python avec FastMCP

FastMCP est le SDK Python officiel de haut niveau. Il gère toute la plomberie du protocole pour que tu puisses te concentrer sur la logique de tes outils.

# Installer FastMCP
pip install fastmcp

# weather_server.py
from fastmcp import FastMCP

mcp = FastMCP("Weather Server")

@mcp.tool()
def get_weather(city: str) -> str:
    """Obtenir la météo actuelle pour une ville."""
    # En production, appeler une vraie API météo ici
    weather_data = {
        "Paris": "Nuageux, 12°C",
        "Tokyo": "Ensoleillé, 22°C",
        "New York": "Pluvieux, 8°C",
    }
    return weather_data.get(city, f"Pas de données pour {city}")

if __name__ == "__main__":
    mcp.run()

C'est tout -- 15 lignes. FastMCP déduit le schéma d'entrée de l'outil à partir des annotations de type Python et de la docstring. Pas de boilerplate JSON Schema.

TypeScript avec le SDK officiel

Le SDK TypeScript (@modelcontextprotocol/sdk) est un peu plus explicite mais te donne un contrôle total sur les définitions de schémas.

# Installer le SDK et Zod pour la validation de schéma
npm install @modelcontextprotocol/sdk zod

// weather-server.ts
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "Weather Server",
  version: "1.0.0",
});

server.tool(
  "get_weather",
  "Obtenir la météo actuelle pour une ville",
  { city: z.string() },
  async ({ city }) => {
    const weatherData: Record<string, string> = {
      Paris: "Nuageux, 12°C",
      Tokyo: "Ensoleillé, 22°C",
      "New York": "Pluvieux, 8°C",
    };
    return {
      content: [
        { type: "text", text: weatherData[city] ?? `Pas de données pour ${city}` },
      ],
    };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

La version TypeScript utilise des schémas Zod au lieu d'annotations de type, et retourne des blocs de contenu structurés. Plus verbeux, mais la sécurité de type est excellente.

Connecter à Claude Desktop

Pour intégrer l'un ou l'autre serveur dans Claude Desktop, ajoute-le à ton claude_desktop_config.json :

{
  "mcpServers": {
    "weather-python": {
      "command": "python",
      "args": ["weather_server.py"],
      "cwd": "/chemin/vers/ton/projet"
    },
    "weather-typescript": {
      "command": "npx",
      "args": ["tsx", "weather-server.ts"],
      "cwd": "/chemin/vers/ton/projet"
    }
  }
}

Redémarre Claude Desktop, et les deux serveurs météo apparaissent dans la liste d'outils. Demande "Quelle est la météo à Paris ?" et le modèle appelle ton outil get_weather automatiquement.

Tester avec MCP Inspector

Avant de connecter ton serveur à un host, teste-le en isolation avec MCP Inspector :

npx @modelcontextprotocol/inspector python weather_server.py

L'Inspector ouvre une interface utilisateur dans le navigateur où tu peux voir les outils découverts, les invoquer manuellement et inspecter les messages JSON-RPC qui circulent. C'est le meilleur outil de débogage dans l'écosystème MCP -- utilise-le tôt et souvent.

Transports MCP : stdio pour le dev, Streamable HTTP pour la production

Les messages MCP ont besoin d'un moyen de circuler entre client et serveur. C'est la couche de transport, et choisir le bon est important.

stdio fonctionne en lançant le serveur MCP comme sous-processus et en communiquant via stdin/stdout. C'est ce que tu as utilisé dans le tutoriel ci-dessus -- pas de ports, pas de TLS, pas d'auth nécessaire. Parfait pour le développement et les outils locaux mono-utilisateur.

Streamable HTTP est le transport de production, ajouté dans la mise à jour de spec 2025. Les clients envoient des requêtes HTTP POST standard au serveur. Le serveur peut répondre de façon synchrone ou ouvrir un stream SSE pour des opérations plus longues. Il est compatible stateless, fonctionne derrière des load balancers et supporte l'authentification HTTP standard.

Si tu vois d'anciens tutoriels mentionnant "HTTP+SSE" comme deux transports séparés (un pour envoyer, un pour recevoir), c'est l'approche dépréciée. Streamable HTTP consolide les deux en un seul mécanisme plus propre.

La décision est simple : utilise stdio lors du développement local, passe à streamable-http lors du déploiement pour d'autres.

// Passer de stdio à Streamable HTTP en TypeScript
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";

const transport = new StreamableHTTPServerTransport({ port: 3001 });
await server.connect(transport);

MCP vs Function Calling vs REST APIs -- Quand utiliser quoi

C'est la question qui revient dans toutes les discussions MCP, alors réglons-la avec une comparaison directe.

Quand le function calling suffit

Si tu as moins de 5 outils et utilises un seul modèle, le function calling est plus simple. Tu définis tes schémas d'outils inline avec chaque appel API, le modèle retourne le nom de la fonction et les arguments, et tu les exécutes dans ton code applicatif. Pas de serveur à faire tourner, pas de protocole à apprendre. Pour un chatbot qui vérifie le statut des commandes et consulte des FAQs, le function calling convient parfaitement.

Quand MCP vaut l'effort

MCP justifie sa complexité quand :

• Tu supportes plusieurs LLMs et ne veux pas réécrire les définitions d'outils pour chaque fournisseur
• Tu as besoin de découverte d'outils -- le modèle peut interroger ce qui est disponible au lieu que tu codeures les schémas en dur
• Tu veux des resources et prompts, pas seulement des appels d'outils
• Tu construis des agents IA qui coordonnent de façon autonome et as besoin d'une couche d'intégration standardisée
• Ton équipe grandit et différents ingénieurs construisent différents outils -- MCP les laisse travailler indépendamment

Verdict : MCP gagne quand tu as besoin d'un accès aux outils standardisé et multi-modèles. Le function calling gagne pour les cas d'usage simples mono-modèle. Les REST APIs restent le bon choix pour la communication service-à-service traditionnelle sans LLM.

L'écosystème MCP en 2026 : Qui le supporte et ce qui est disponible

MCP est passé d'un projet annexe d'Anthropic à un standard industriel en moins de 18 mois. Voici où en sont les choses.

Quels LLMs supportent MCP ?

Serveurs MCP populaires à connaître

L'annonce de l'AAIF de la Linux Foundation a cité 10 000+ serveurs actifs et 97 millions de téléchargements mensuels du SDK lors de la donation de MCP en décembre 2025. L'écosystème n'est plus expérimental -- il est prêt pour la production.

MCP Apps est une nouvelle primitive introduite en janvier 2026. Elle permet aux serveurs de fournir des composants UI interactifs qui se rendent dans l'application host. Encore précoce, mais cela signale l'évolution de MCP d'un protocole de données vers un framework complet d'application agentique. À surveiller.

Gouvernance : D'Anthropic à la Linux Foundation

MCP est gouverné par l'Agentic AI Foundation (AAIF) sous la Linux Foundation, co-fondée par Anthropic, Block et OpenAI. Cela compte pour l'adoption en entreprise : MCP n'est pas lié à la feuille de route d'un seul vendeur. La feuille de route 2026 se concentre sur l'évolution du transport, la communication agent-à-agent (une nouvelle primitive "Tasks"), la maturation de la gouvernance et la préparation à l'entreprise.

Pour les équipes qui construisent des systèmes IA en production, des frameworks comme un framework d'agents IA autonomes comme OpenClaw s'intègrent déjà avec des serveurs MCP pour donner aux agents des capacités réelles.

Sécurité MCP : OAuth 2.1, menaces et liste de contrôle pratique

La sécurité est là où l'écosystème MCP a le plus de terrain à couvrir. Et les chiffres brossent un tableau saisissant.

Le problème des 88% : Pourquoi la plupart des serveurs MCP sont non sécurisés

Astrix Security a analysé 5 200+ implémentations de serveurs MCP open source et a constaté que 88% nécessitent des identifiants d'une sorte ou d'une autre -- mais 53% s'appuient sur des secrets statiques à longue durée de vie non sécurisés comme des clés API et des tokens d'accès personnels codés en dur dans des fichiers de configuration. Seulement 8,5% implémentent OAuth.

Cela signifie que la grande majorité des serveurs MCP dans la nature utilise l'équivalent d'authentification de coller ta clé de maison sur la porte d'entrée.

OAuth 2.1 pour les serveurs MCP

La spécification MCP exige OAuth 2.1 pour tous les serveurs basés sur HTTP depuis la mise à jour de juin 2025. Le flux fonctionne ainsi : le client MCP initie un flux d'autorisation OAuth 2.1 avec le serveur, obtient un token d'accès limité, et l'inclut dans chaque requête ultérieure. PKCE (Proof Key for Code Exchange) est requis pour tous les clients -- sans exception.

Si tu construis un serveur MCP qui tourne sur Streamable HTTP, OAuth 2.1 n'est pas optionnel. C'est exigé par la spécification.

Modèle de menace : Ce qui peut mal tourner

Quatre menaces méritent attention dans tout déploiement MCP :

• Injection de prompt via les outils -- Une source de données malveillante ou compromise retourne du contenu conçu pour manipuler le modèle. Si un outil récupère une page web et que cette page contient des instructions cachées, le modèle pourrait les exécuter.
• Attaque du deputy confus -- Le modèle invoque un outil avec des permissions plus larges que l'utilisateur ne le souhaitait. Si le serveur MCP a un accès administrateur à une base de données, le modèle pourrait théoriquement supprimer une table.
• Risque de concentration des tokens -- Un serveur MCP qui détient des clés API pour GitHub, Slack et ta base de données de production est une cible unique de grande valeur. Compromettre un serveur, c'est compromettre tout ce à quoi il se connecte.
• Transport non sécurisé -- Faire tourner un serveur MCP HTTP sans TLS expose chaque requête, y compris les tokens OAuth et les données sensibles, en clair.

Liste de contrôle sécurité pour MCP en production

1. Implémenter OAuth 2.1 pour tout serveur exposé via HTTP. Pas de clés API statiques dans les fichiers de configuration.
2. Appliquer le scoping de moindre privilège. Si ton outil ne fait que lire des données, les identifiants du serveur doivent être en lecture seule. N'accorde pas un accès en écriture à un outil de reporting.
3. Isoler les identifiants. Chaque serveur MCP doit avoir ses propres tokens limités. Ne partage pas un seul "token god" entre serveurs.
4. Imposer TLS partout. Streamable HTTP sans HTTPS est un non-go automatique pour la production.
5. Valider et assainir les sorties des outils. Traite les données retournées par les outils comme tu traiterais des entrées utilisateur -- ne leur fais pas aveuglément confiance.
6. Limiter le débit des invocations d'outils. Une boucle d'agent incontrôlée appelant un outil des milliers de fois peut épuiser les quotas API ou causer des effets secondaires non souhaités.
7. Auditer et journaliser chaque appel d'outil. Inclus les IDs de requête, les horodatages, le modèle appelant et les arguments de l'outil. Tu en as besoin pour le débogage et la réponse aux incidents de sécurité.

Débogage MCP : Inspector, journalisation et erreurs courantes

Tu rencontreras des erreurs. Tout développeur en rencontre. Voici comment les corriger rapidement.

MCP Inspector est l'outil de débogage officiel et ta première ligne de défense. Il se connecte à n'importe quel serveur MCP, découvre ses outils/resources/prompts et te laisse les invoquer manuellement tout en affichant le trafic JSON-RPC brut.

# Lancer Inspector contre ton serveur Python
npx @modelcontextprotocol/inspector python weather_server.py

# Ou contre un serveur TypeScript
npx @modelcontextprotocol/inspector npx tsx weather-server.ts

L'Inspector ouvre une interface utilisateur dans le navigateur avec des onglets pour Outils, Resources, Prompts et un volet de notifications. Tu peux appeler n'importe quel outil avec des arguments personnalisés et voir exactement quel JSON passe sur le réseau. Utilise-le avant de te connecter à une application host -- il est bien plus facile de déboguer le serveur en isolation.

Erreurs courantes et corrections

• "Serveur non trouvé" dans Claude Desktop -- Presque toujours un problème de chemin dans claude_desktop_config.json. Vérifie que command se résout en un vrai binaire et que cwd pointe vers le bon répertoire. Sur macOS, utilise des chemins absolus.
• Échecs de validation de schéma d'outil -- Si le modèle envoie des arguments qui ne correspondent pas au inputSchema de l'outil, le serveur rejette l'appel. Vérifie que tes types de schéma correspondent à ce que le modèle attend. Zod (TypeScript) et les annotations de type (Python) attrappent la plupart d'entre eux au moment de la définition.
• Coupures de connexion de transport -- Pour stdio, cela signifie généralement que le processus serveur a planté. Vérifie la sortie stderr. Pour Streamable HTTP, vérifie les paramètres de timeout -- les outils à longue durée d'exécution peuvent dépasser les timeouts HTTP par défaut.
• Erreurs "Permission denied" ou 401 -- Scope OAuth trop étroit. Le serveur rejette le token car il n'a pas les permissions requises. Élargis le scope, mais uniquement autant que l'outil en a réellement besoin.

Meilleures pratiques de journalisation

Structure tes logs avec des IDs de requête pour pouvoir tracer une seule requête utilisateur à travers le client MCP, le serveur et toutes les APIs en aval. Journalise chaque invocation tools/call avec le nom de l'outil, les arguments, le temps de réponse et le statut du résultat. En production, envoie ces logs vers une plateforme d'observabilité -- quand quelque chose se passe mal à 3h du matin, tu seras content de l'avoir fait.

Comment Techsy construit avec MCP

Nous intégrons MCP dans des projets clients depuis début 2025, et le schéma que nous voyons le plus souvent est celui-ci : une équipe a une fonctionnalité IA qui fonctionne avec un modèle et quelques outils, mais prévoit de monter en charge -- plus de modèles, plus de sources de données, plus de capacités agentiques. C'est le point d'inflexion où MCP commence à porter ses fruits.

Notre approche suit trois étapes :

1. Évaluer l'adéquation. Tous les projets n'ont pas besoin de MCP. Si tu appelles deux outils depuis un seul modèle, le function calling est plus simple et nous te le dirons. MCP a du sens quand tu connectes 3+ sources de données, supportes plusieurs modèles, ou construis des workflows d'agents où les outils doivent être découvrables.
2. Construire et tester les serveurs en isolation. Nous développons des serveurs MCP personnalisés pour chaque source de données -- bases de données internes, APIs SaaS, services propriétaires -- et les validons avec MCP Inspector avant de les connecter à un host.
3. Déployer avec Streamable HTTP et OAuth 2.1. Pour la production, nous faisons tourner les serveurs MCP en tant que services conteneurisés derrière TLS, avec des tokens OAuth limités et une journalisation structurée dès le premier jour. Pas de secrets statiques.

Les intégrations les plus courantes que nous construisons : connecter des assistants IA à des bases de données Postgres internes, construire des serveurs MCP personnalisés pour les plateformes SaaS de clients, et migrer des équipes de configurations function calling éparpillées vers une architecture MCP standardisée.

Tu construis des outils alimentés par l'IA qui doivent se connecter à ton infrastructure ? Nous aidons les équipes à concevoir et implémenter des intégrations MCP. Obtenir une consultation gratuite

Questions fréquemment posées sur MCP

Qu'est-ce que le Model Context Protocol (MCP) ?

MCP est un standard ouvert, créé à l'origine par Anthropic et désormais gouverné par la Linux Foundation, qui définit comment les modèles IA se connectent à des outils externes, des sources de données et des services. Il standardise la couche d'intégration afin qu'un serveur MCP fonctionne avec n'importe quel modèle compatible -- comme une prise universelle pour l'IA.

Comment fonctionne MCP ?

MCP utilise une architecture en trois parties : une application host (comme Claude Desktop ou Cursor), un client MCP à l'intérieur du host qui gère les connexions, et des serveurs MCP qui exposent des outils et des données. Toute communication utilise des messages JSON-RPC 2.0 sur stdio (local) ou Streamable HTTP (distant).

À quoi sert MCP ?

Les cas d'usage courants incluent la connexion d'assistants IA à des bases de données (Postgres, MySQL), l'intégration avec des plateformes de code (GitHub, GitLab), l'accès à des outils SaaS (Slack, Notion, Google Drive), et la construction d'agents IA autonomes qui ont besoin d'interagir avec des services réels.

MCP est-il la même chose que le function calling ?

Non. Le function calling est spécifique au modèle (le format d'OpenAI diffère de celui d'Anthropic) et par requête -- tu envoies des schémas d'outils avec chaque appel API. MCP est un protocole standardisé qui fonctionne sur plusieurs modèles, supporte la découverte d'outils, et inclut des resources et des prompts au-delà de la simple exécution de fonctions.

Que sont les serveurs MCP ?

Les serveurs MCP sont des programmes qui exposent des outils, des resources et des prompts aux modèles IA via le protocole MCP. Ils encapsulent des APIs externes et des sources de données dans une interface standardisée. Les exemples incluent le serveur MCP GitHub (pour la gestion des PRs et issues) et le serveur MCP Postgres (pour les requêtes de bases de données).

Comment construire un serveur MCP ?

Utilise Python avec FastMCP (pip install fastmcp) ou TypeScript avec le SDK officiel (npm install @modelcontextprotocol/sdk). Définis tes outils comme des fonctions décorées (Python) ou des handlers enregistrés (TypeScript), puis lance le serveur. Voir la section tutoriel ci-dessus pour du code fonctionnel complet.

MCP est-il sécurisé ?

Le protocole lui-même supporte OAuth 2.1 pour l'authentification et des permissions limitées. Cependant, la recherche d'Astrix Security a montré que 88% des implémentations de serveurs MCP existantes s'appuient sur des secrets statiques plutôt que sur OAuth. Le protocole est sécurisé par design, mais la plupart des déploiements réels n'ont pas encore rattrapé leur retard.

Quels LLMs supportent MCP ?

Claude a un support MCP natif depuis sa création en novembre 2024. ChatGPT a ajouté le support en mars 2025, et Gemini a suivi en avril 2025. Les modèles open source peuvent utiliser MCP via des adaptateurs dans LangChain et LlamaIndex.

Quelle est la différence entre MCP et une REST API ?

Les REST APIs sont conçues pour la communication service-à-service générale. MCP est conçu spécifiquement pour l'interaction avec les modèles IA -- il inclut la découverte d'outils, la négociation de schémas, l'accès aux resources et des templates de prompts que REST n'a pas. Tu ne remplacerait pas tes REST APIs par MCP ; elles servent des couches différentes.

Qui maintient MCP maintenant ?

L'Agentic AI Foundation (AAIF) de la Linux Foundation, formée en décembre 2025, gouverne MCP. Elle a été co-fondée par Anthropic, Block et OpenAI. Cette gouvernance neutre vis-à-vis des vendeurs est une raison clé pour laquelle les entreprises adoptent MCP.

Qu'est-ce que Streamable HTTP dans MCP ?

Streamable HTTP est le mécanisme de transport de production ajouté dans la mise à jour de spec MCP 2025. Il remplace l'ancien transport HTTP+SSE par un design plus propre : les clients envoient des requêtes HTTP POST, et les serveurs peuvent répondre de façon synchrone ou via streaming SSE. Il fonctionne derrière des load balancers et supporte l'authentification HTTP standard.

Combien de serveurs MCP existent ?

La Linux Foundation a cité 10 000+ serveurs actifs et 97 millions de téléchargements mensuels du SDK quand MCP a été donné à l'AAIF en décembre 2025. L'écosystème s'étend aux bases de données, outils de code, intégrations SaaS, moteurs de recherche et fournisseurs d'infrastructure cloud.

Conclusion

MCP est passé de l'expérience open source d'Anthropic au protocole standard de l'industrie pour connecter les modèles IA aux outils en un peu plus d'un an. Voici ce qui compte :

• MCP résout le problème M x N -- un serveur fonctionne avec chaque modèle compatible, un client fonctionne avec chaque serveur
• Tu peux construire un serveur MCP fonctionnel en moins de 50 lignes de Python (FastMCP) ou TypeScript
• Utilise stdio pour le développement, Streamable HTTP pour la production -- le choix du transport est simple
• Sécurise tes serveurs avec OAuth 2.1 -- 88% des implémentations actuelles ne le font pas, et c'est un vrai risque
• L'écosystème est prêt pour la production -- 10 000+ serveurs, tous les grands LLMs, gouvernance neutre sous la Linux Foundation

En regardant vers l'avenir, la feuille de route 2026 se concentre sur la communication agent-à-agent via une nouvelle primitive Tasks, une sécurité entreprise améliorée, et MCP Apps pour une interface utilisateur interactive pilotée par le serveur. MCP n'est plus seulement un protocole pour l'accès aux outils -- il devient la couche d'infrastructure pour l'IA agentique.

Commence avec le code du tutoriel ci-dessus, teste-le dans MCP Inspector, et connecte-le à Claude Desktop. Tu auras une intégration MCP fonctionnelle en moins d'une heure.

Sources

• Spécification MCP (2025-11-25)
• Spécification d'autorisation MCP
• Spécification des transports MCP
• Documentation MCP Inspector
• Présentation du Model Context Protocol -- Anthropic
• Don de MCP à la Linux Foundation -- Anthropic
• Annonce AAIF de la Linux Foundation
• Support MCP Google Cloud
• FastMCP Python SDK
• MCP TypeScript SDK
• Astrix Security : État de la sécurité des serveurs MCP 2025
• Feuille de route MCP 2026