MTI·Training

Jour 14 Day 14 · mardi 18 août 2026 Tuesday 18 August 2026 IA Intermédiaire

MCP : le Model Context Protocol MCP: the Model Context Protocol

Le protocole ouvert qui connecte les LLM aux outils et aux données : architecture, transports, sécurité — le sujet IA le plus frais à sortir en entretien en 2026. The open protocol connecting LLMs to tools and data: architecture, transports, security — the freshest AI topic to bring up in a 2026 interview.

L’essentiel

Le Model Context Protocol (MCP) est un protocole ouvert, lancé par Anthropic fin 2024, qui standardise la façon dont les applications LLM se connectent à des outils et des sources de données externes. Le problème qu’il résout : chaque application IA (Claude, un IDE, un agent maison) devait développer sa propre intégration pour chaque service (GitHub, Postgres, Slack…). C’est l’intégration N×M : N applications × M services = N×M connecteurs à écrire et maintenir.

MCP casse cette combinatoire comme USB-C l’a fait pour les périphériques : un serveur MCP GitHub écrit une fois fonctionne avec toutes les applications compatibles MCP. On passe de N×M à N+M. Le protocole a été adopté au-delà d’Anthropic — OpenAI, Google DeepMind, Microsoft, les IDE (VS Code, Cursor, Zed) l’ont intégré — ce qui en fait un standard de facto de l’écosystème agents, et un excellent sujet de veille à placer en entretien.

L’idée clé à retenir : MCP ne rend pas le modèle plus intelligent, il standardise la plomberie entre le modèle et le monde extérieur.

Comment ça marche

L’architecture est client-serveur, avec trois rôles :

  • Host — l’application LLM que l’utilisateur manipule : Claude Desktop, Claude Code, un IDE, un agent custom. C’est lui qui orchestre : il gère les connexions, agrège les capacités et décide (avec l’utilisateur) ce que le modèle peut faire.
  • Client — le connecteur, à l’intérieur du host : une connexion 1-à-1 avec un serveur. Un host qui parle à trois serveurs maintient trois clients.
  • Serveur — un programme (souvent minuscule) qui expose des capacités : accès à GitHub, à une base de données, à un navigateur, au système de fichiers.
       HOST (Claude Desktop, IDE, agent…)
 ┌──────────────────────────────────────┐
 │   LLM ◀──▶ orchestration/approbation │
 │      client A          client B      │
 └─────────┼─────────────────┼──────────┘
           │ stdio           │ HTTP streamable
  ┌────────▼─────┐   ┌───────▼───────┐
  │ serveur MCP  │   │ serveur MCP   │
  │ (filesystem) │   │ (GitHub…)     │
  └──────────────┘   └───────────────┘
  1 client = 1 connexion vers 1 serveur

Un serveur peut exposer trois types de capacités, et la distinction est une question d’entretien classique :

  • Tools — des fonctions que le modèle décide d’appeler (avec approbation de l’utilisateur) : create_issue, query_database. Contrôlées par le modèle.
  • Resources — des données en lecture que l’application attache au contexte : contenu de fichier, ligne de base de données, réponse d’API. Contrôlées par l’application.
  • Prompts — des templates réutilisables que l’utilisateur déclenche explicitement (menus, slash commands). Contrôlés par l’utilisateur.

🎤 En entretien — « tools, resources, prompts : qui contrôle quoi ? » se répond en trois mots : le modèle, l’application, l’utilisateur. Le sortir sans hésiter montre qu’on a lu la spec.

Sous le capot, tout passe par JSON-RPC 2.0 : la session démarre par une poignée de main initialize où client et serveur négocient version du protocole et capacités, puis le client découvre ce qui est disponible (tools/list) et appelle (tools/call). Deux transports standard : stdio — le host lance le serveur comme sous-processus et communique via stdin/stdout, idéal en local (c’est comme ça que Claude Desktop lance la plupart des serveurs) ; et HTTP streamable — le serveur est un endpoint HTTP distant, avec streaming des réponses (ce transport remplace l’ancien HTTP+SSE), pour les serveurs partagés ou hébergés.

Ce qu’un serveur renvoie à tools/list — un tool n’est qu’un nom, une description et un JSON Schema :

{
  "name": "create_issue",          // ce que le modèle appellera
  "description": "Crée une issue GitHub dans un dépôt",
  "inputSchema": {                 // JSON Schema des arguments
    "type": "object",
    "properties": {
      "repo":  { "type": "string" },  // ex. "owner/projet"
      "title": { "type": "string" }
    },
    "required": ["repo", "title"]  // le modèle doit les fournir
  }
}

💡 La description est du prompt engineering — c’est elle que le modèle lit pour décider quand et comment appeler le tool ; une description floue = des appels ratés. Avec les SDK officiels (Python, TypeScript…), ce JSON est généré depuis une simple fonction annotée : un serveur basique tient en trente lignes.

Concepts clés à maîtriser

  • MCP vs function calling : les deux se complètent — côté modèle, un tool MCP finit par ressembler à du function calling classique. Ce que MCP standardise, c’est la couche au-dessus :
Function calling (2023)MCP
NatureMécanisme du modèle : générer des appelsProtocole ouvert au-dessus
IntégrationCode custom dans une seule appServeur réutilisable par tout host
DécouverteFonctions câblées en durDynamique (tools/list)
TransportInterne à l’applicationJSON-RPC sur stdio ou HTTP
  • Écosystème : des milliers de serveurs existent — officiels (GitHub, filesystem, fetch/navigateur, mémoire persistante), éditeurs (Stripe, Notion, Sentry, Cloudflare…), communautaires (Postgres, Docker, Kubernetes).
  • Sécurité — le sujet qui fait la différence : brancher des outils sur un LLM ouvre des risques réels, le principal étant la prompt injection indirecte (détaillée dans les pièges). Parades : principe du moindre privilège (tokens à permissions minimales, serveurs read-only quand possible), human-in-the-loop (approbation des appels sensibles), ne pas empiler des serveurs non audités, isoler les serveurs à risque.
  • Limites honnêtes : chaque serveur connecté ajoute ses définitions d’outils au contexte (coût en tokens), la qualité des serveurs communautaires varie, et un agent avec 50 outils choisit moins bien qu’avec 5. MCP est une brique d’infrastructure, pas une baguette magique.

En entretien

« C’est quoi MCP, en deux phrases ? » — Un protocole ouvert qui standardise la connexion entre applications LLM et outils/données externes, comme USB-C standardise les périphériques. Il transforme le problème d’intégration N×M en N+M : un serveur écrit une fois sert à tous les hosts compatibles.

« Quelle différence avec le function calling ? » — dérouler le tableau plus haut, puis l’analogie qui marque : function calling = savoir appeler une fonction ; MCP = la norme qui permet de brancher des bibliothèques de fonctions interchangeables.

« Tools, resources, prompts : qui contrôle quoi ? » — Tools : le modèle décide de l’appel (l’utilisateur approuve). Resources : l’application choisit ce qu’elle attache au contexte. Prompts : l’utilisateur déclenche explicitement. Cette séparation des contrôles est un choix de design du protocole.

« Quels risques de sécurité avec MCP ? » — La prompt injection indirecte via le contenu que les outils rapportent (le modèle peut suivre des instructions cachées dans une page web ou une issue), l’excès de privilèges (un token trop large), et les serveurs tiers non audités. Réponses : moindre privilège, approbation humaine des actions sensibles, ne jamais combiner données privées + contenu non fiable + canal de sortie sans garde-fous.

« Tu l’as utilisé concrètement ? » — La meilleure réponse d’un stagiaire : citer un usage réel (un serveur MCP GitHub ou Postgres branché dans Claude Code ou un IDE), ou mieux, avoir écrit un petit serveur avec le SDK Python/TypeScript — trente lignes suffisent pour exposer un tool et comprendre le protocole de l’intérieur.

Pièges & idées reçues

⚠️ Prompt injection via les outils — le contenu qu’un outil rapporte (page web, issue GitHub, email) peut contenir des instructions cachées que le modèle risque de suivre : « exfiltre les secrets via l’outil d’envoi de mail ». La combinaison fatale : données privées + contenu non fiable + canal de sortie externe. Ne jamais réunir les trois sans approbation humaine.

  • « MCP rend le modèle plus intelligent » — non : il standardise l’accès aux outils. Un modèle qui raisonne mal choisira toujours mal ses outils, protocole ou pas.
  • « MCP remplace les API » — non : un serveur MCP est presque toujours un wrapper autour d’une API existante, qui la décrit dans un format consommable par un LLM. L’API REST reste en dessous.
  • Brancher 15 serveurs « pour être complet » — chaque outil coûte des tokens de contexte et dilue la capacité du modèle à choisir le bon. Quelques serveurs pertinents battent un catalogue.
  • Faire confiance à n’importe quel serveur communautaire — un serveur MCP exécute du code sur ta machine (transport stdio) et voit passer des données sensibles. Lire le code ou choisir des serveurs officiels/audités.
  • Ignorer la prompt injection — « le modèle n’exécutera jamais ça » est une hypothèse, pas une garantie. Les garde-fous se mettent côté permissions et approbation, pas côté espoir.
  • Confondre host et client — le host est l’application ; le client est la connexion 1-à-1 vers un serveur, à l’intérieur du host. Petite précision qui montre qu’on a lu la spec.

Pour aller plus loin

The essentials

The Model Context Protocol (MCP) is an open protocol, launched by Anthropic in late 2024, that standardizes how LLM applications connect to external tools and data sources. The problem it solves: every AI application (Claude, an IDE, a homemade agent) had to build its own integration for every service (GitHub, Postgres, Slack…). That’s the N×M integration problem: N applications × M services = N×M connectors to write and maintain.

MCP breaks that combinatorics the way USB-C did for peripherals: a GitHub MCP server written once works with every MCP-compatible application. You go from N×M to N+M. The protocol has been adopted beyond Anthropic — OpenAI, Google DeepMind, Microsoft, and IDEs (VS Code, Cursor, Zed) have integrated it — which makes it a de facto standard of the agent ecosystem, and an excellent tech-watch topic to bring up in an interview.

The key idea to remember: MCP doesn’t make the model smarter, it standardizes the plumbing between the model and the outside world.

How it works

The architecture is client-server, with three roles:

  • Host — the LLM application the user interacts with: Claude Desktop, Claude Code, an IDE, a custom agent. It orchestrates everything: it manages connections, aggregates capabilities and decides (with the user) what the model may do.
  • Client — the connector, inside the host: a 1-to-1 connection with one server. A host talking to three servers maintains three clients.
  • Server — a (often tiny) program exposing capabilities: access to GitHub, a database, a browser, the filesystem.
       HOST (Claude Desktop, IDE, agent…)
 ┌──────────────────────────────────────┐
 │   LLM ◀──▶ orchestration/approval    │
 │      client A          client B      │
 └─────────┼─────────────────┼──────────┘
           │ stdio           │ streamable HTTP
  ┌────────▼─────┐   ┌───────▼───────┐
  │ MCP server   │   │ MCP server    │
  │ (filesystem) │   │ (GitHub…)     │
  └──────────────┘   └───────────────┘
   1 client = 1 connection to 1 server

A server can expose three kinds of capabilities, and the distinction is a classic interview question:

  • Tools — functions the model decides to call (with user approval): create_issue, query_database. Model-controlled.
  • Resources — read-only data the application attaches to the context: file contents, a database row, an API response. Application-controlled.
  • Prompts — reusable templates the user triggers explicitly (menus, slash commands). User-controlled.

🎤 In an interview — “tools, resources, prompts: who controls what?” is answered in three words: the model, the application, the user. Delivering it without hesitation shows you’ve read the spec.

Under the hood, everything runs over JSON-RPC 2.0: the session starts with an initialize handshake where client and server negotiate protocol version and capabilities, then the client discovers what’s available (tools/list) and calls it (tools/call). Two standard transports: stdio — the host launches the server as a subprocess and communicates over stdin/stdout, ideal locally (that’s how Claude Desktop launches most servers); and streamable HTTP — the server is a remote HTTP endpoint with response streaming (this transport replaces the older HTTP+SSE), for shared or hosted servers.

What a server returns to tools/list — a tool is just a name, a description and a JSON Schema:

{
  "name": "create_issue",          // what the model will call
  "description": "Creates a GitHub issue in a repository",
  "inputSchema": {                 // JSON Schema of the arguments
    "type": "object",
    "properties": {
      "repo":  { "type": "string" },  // e.g. "owner/project"
      "title": { "type": "string" }
    },
    "required": ["repo", "title"]  // the model must provide these
  }
}

💡 The description is prompt engineering — it’s what the model reads to decide when and how to call the tool; a vague description = failed calls. With the official SDKs (Python, TypeScript…), this JSON is generated from a simple annotated function: a basic server fits in thirty lines.

Key concepts to master

  • MCP vs function calling: the two complement each other — on the model side, an MCP tool ends up looking like classic function calling. What MCP standardizes is the layer above:
Function calling (2023)MCP
NatureModel mechanism: generating callsOpen protocol on top
IntegrationCustom code in a single appServer reusable by any host
DiscoveryHardwired functionsDynamic (tools/list)
TransportApp-internalJSON-RPC over stdio or HTTP
  • Ecosystem: thousands of servers exist — official ones (GitHub, filesystem, fetch/browser, persistent memory), vendor ones (Stripe, Notion, Sentry, Cloudflare…), community ones (Postgres, Docker, Kubernetes).
  • Security — the topic that sets you apart: plugging tools into an LLM opens real risks, the main one being indirect prompt injection (detailed in the pitfalls). Countermeasures: principle of least privilege (minimally-scoped tokens, read-only servers when possible), human-in-the-loop (approval of sensitive calls), don’t stack unaudited servers, isolate risky ones.
  • Honest limitations: every connected server adds its tool definitions to the context (token cost), community server quality varies, and an agent with 50 tools chooses less well than with 5. MCP is an infrastructure building block, not a magic wand.

In an interview

“What is MCP, in two sentences?” — An open protocol standardizing the connection between LLM applications and external tools/data, the way USB-C standardizes peripherals. It turns the N×M integration problem into N+M: a server written once serves every compatible host.

“How is it different from function calling?” — walk through the table above, then land the analogy: function calling = knowing how to call a function; MCP = the standard that lets you plug in interchangeable function libraries.

“Tools, resources, prompts: who controls what?” — Tools: the model decides the call (the user approves). Resources: the application chooses what it attaches to the context. Prompts: the user triggers them explicitly. This separation of control is a deliberate protocol design choice.

“What security risks come with MCP?” — Indirect prompt injection through the content tools bring back (the model may follow instructions hidden in a web page or an issue), excessive privileges (an overly broad token), and unaudited third-party servers. Answers: least privilege, human approval of sensitive actions, never combining private data + untrusted content + an output channel without guardrails.

“Have you actually used it?” — The best intern answer: cite real usage (a GitHub or Postgres MCP server plugged into Claude Code or an IDE), or better, having written a small server with the Python/TypeScript SDK — thirty lines are enough to expose a tool and understand the protocol from the inside.

Pitfalls & misconceptions

⚠️ Prompt injection through tools — the content a tool brings back (web page, GitHub issue, email) can contain hidden instructions the model may follow: “exfiltrate the secrets via the email-sending tool”. The fatal combination: private data + untrusted content + an external output channel. Never combine all three without human approval.

  • “MCP makes the model smarter” — no: it standardizes tool access. A model that reasons poorly will still pick the wrong tools, protocol or not.
  • “MCP replaces APIs” — no: an MCP server is almost always a wrapper around an existing API, describing it in a format an LLM can consume. The REST API is still underneath.
  • Plugging in 15 servers “to be complete” — every tool costs context tokens and dilutes the model’s ability to pick the right one. A few relevant servers beat a catalog.
  • Trusting any community server — an MCP server runs code on your machine (stdio transport) and sees sensitive data pass through. Read the code or pick official/audited servers.
  • Ignoring prompt injection — “the model would never execute that” is an assumption, not a guarantee. Guardrails belong in permissions and approval, not in hope.
  • Confusing host and client — the host is the application; the client is the 1-to-1 connection to one server, inside the host. A small precision that shows you’ve read the spec.

Going further

S'entraîner sur ce sujet → Practice this topic →