MCP (Model Context Protocol) expliqué : comment configurer les sources de données pour votre Agent IA ?

En bref : l'Agent sait écrire du code, mais ne lit pas vos Issues GitHub, le schéma de base ni la doc interne — le problème vient souvent de la source des données, pas du modèle. Cet article part du protocole MCP : couches d'architecture, trois primitives Tools / Resources / Prompts, stdio vs HTTP, puis exemples de configuration et checklist de validation pour Cursor et Claude Code. Vous pourrez brancher les sources courantes sans glue code par SaaS.

Articles connexes : Tutoriel d'installation MCP pour Claude Code · 20 MCP Server recommandés · Exposition minimale des permissions MCP

Qu'est-ce que MCP ? Quel problème résout-il ?

Le Model Context Protocol (MCP) est une norme ouverte publiée fin 2024 par Anthropic. Objectif : permettre aux applications IA (Hosts) de se connecter au monde extérieur — dépôts, bases, documentation, ticketing, navigateur — de façon unifiée et auditable, sans intégration sur mesure par source.

Avant MCP, deux approches dominaient :

• Copier-coller manuel — liens d'issues, résultats SQL, réponses API dans le chat. Précis mais lent, non scalable.
• Function Calling maison — schema et auth par GitHub, Postgres, Notion. Flexible mais coûteux ; changement de client (Cursor → Claude Code) = souvent tout refaire.

MCP propose une troisième voie : standardiser l'interface « source de données ↔ Agent ». Un GitHub MCP configuré une fois sert Cursor, Claude Code, VS Code Copilot, OpenAI Codex ; la communauté maintient des milliers de Servers pour SaaS et outils de dev.

Trois couches : Host, Client, Server

Pour configurer MCP, comprendre d'abord les trois rôles :

Chaîne typique : vous demandez dans Cursor « Quels fichiers PR #42 a-t-il modifiés ? » → Host → modèle choisit mcp__github__get_pull_request → Client envoie via stdio ou HTTP au GitHub MCP → Server appelle l'API GitHub → JSON structuré → réponse basée sur des données réelles.

Point clé : vous configurez la connexion Server (commande, URL, variables d'environnement). Le Host découvre automatiquement les tools — pas de doc API à recopier dans le prompt : au démarrage, tools/list pousse la liste des capacités.

Trois primitives : Tools, Resources, Prompts

Un MCP Server expose trois types de capacités, pour des modes d'accès différents :

Tools — « Permettre à l'Agent d'agir »

Le plus courant. Chaque Tool a nom, description et schema d'entrée (JSON Schema) ; l'Agent l'invoque à la demande. Exemples : GitHub MCP search_code, Playwright MCP browser_click, MCP base execute_query.

Lors du branchement de sources : ~90 % des cas = Servers orientés Tools — lire un repo, interroger des tables, HTTP, piloter un navigateur.

Resources — « Contexte statique lisible »

Les Resources sont des fragments de données adressables, comme des fichiers en lecture seule avec URI. Le Server déclare file://docs/api.md ou db://schema/users ; le Host peut charger le contenu avant ou pendant la conversation — sans que l'Agent devine quel Tool appeler.

Adapté à : README, spec OpenAPI, snapshot de schéma DB, modèles de config — connaissance relativement stable et énumérable.

Prompts — « Points d'entrée de workflow prédéfinis »

Le Server peut exposer des modèles de prompt nommés (avec paramètres) — « Code Review », « script de migration », etc. Moins répandu que les Tools dans la communauté, mais utile pour encapsuler les SOP d'équipe.

Types de sources et MCP Server courants

Ce tableau relie « que veux-je brancher ? » à « quel Server ? ». Liste complète de 20 Servers : MCP Server recommandés 2026.

Couche transport : stdio ou HTTP ?

Client et Server MCP communiquent en JSON-RPC 2.0. En 2026, deux transports dominent :

stdio (entrée/sortie standard)

Le Host lance le Server en sous-processus, ex. npx -y @modelcontextprotocol/server-github, messages via stdin/stdout. Avantages : config simple, pas de port ouvert, idéal en local. Inconvénients : un processus par Server ; versions Docker complètes peuvent dépasser la limite ~40 tools de Cursor.

Streamable HTTP / SSE (Remote)

Server distant ou hébergé officiellement ; Client en HTTPS, souvent OAuth. GitHub, Supabase, Linear, Sentry proposent des variantes Remote. Avantages : jeux d'outils allégés, pas de Node/Docker local, tokens via OAuth. Inconvénients : dépendance réseau ; vérifier l'egress en entreprise.

Configurer les sources dans Cursor

Cursor : Settings → MCP ou ~/.cursor/mcp.json. Structure : objet mcpServers, une entrée par Server.

Exemple 1 : stdio local — Fetch MCP

{
  "mcpServers": {
    "fetch": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-fetch"]
    }
  }
}

Exemple 2 : stdio local — GitHub MCP (PAT)

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    }
  }
}

Mieux : GitHub Remote MCP officiel dans l'UI Cursor (OAuth) — moins de tools, pas de PAT en JSON. PAT fin en read-only ; ne jamais committer dans git.

Exemple 3 : Context7 (source documentation)

{
  "mcpServers": {
    "context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

Après sauvegarde, redémarrer Cursor ; Settings → MCP doit afficher Connected en vert. En mode Agent : « syntaxe middleware Next.js 15 ? » — si la config est bonne, le modèle appelle Context7 au lieu d'halluciner.

Configurer les sources dans Claude Code

Claude Code : ~/.claude.json (utilisateur) ou .mcp.json à la racine du projet. Structure proche de Cursor, chemins légèrement différents.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxxxxxxx"
      }
    },
    "codegraph": {
      "command": "codegraph",
      "args": ["mcp"]
    }
  }
}

Après modification, quitter complètement Claude Code et relancer ; à la racine du repo, lancer claude, saisir /mcp pour voir Servers et tools. Succès : préfixes mcp__github__*, mcp__codegraph__*.

Guide pas à pas : Tutoriel d'installation MCP pour Claude Code ; vue d'ensemble : Chaîne MCP GitHub Files API.

Niveau projet vs utilisateur : où écrire la config ?

Bonne pratique : identifiants et préférences au niveau utilisateur (hors git) ; sources liées au dépôt (chemin CodeGraph, Server doc projet) dans .mcp.json versionné — clone-and-go pour l'équipe. Tokens sensibles via variable d'environnement, ex. "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}" }, injectée par le shell ou la CI.

Validation : l'Agent utilise vraiment la source

Configuré ≠ opérationnel. Checklist :

1. Connexion — Cursor : MCP vert dans Settings ; Claude Code : /mcp sans error.
2. Tools visibles — Le tool cible existe, ex. mcp__github__search_code.
3. Smoke test — Instruction claire : « Lister les open issues de ce repo via GitHub MCP » ou « Context7 : syntaxe migrate Prisma récente ».
4. Échecs observables — Si l'Agent n'appelle rien : trop de tools, consigne vague ; préciser « utiliser GitHub MCP ».
5. Limite de permissions — Action interdite (supprimer un repo) doit renvoyer 403, pas un succès silencieux.

Permissions et limites de sécurité

Chaque source ouvre une porte vers l'extérieur pour l'Agent. Principe : read-only par défaut, écriture explicite, production isolée.

• GitHub PAT — Token fin, repos ciblés ; Issues/Contents read-only suffisent pour la plupart des cas dev.
• DSN base — Rôle read-only sur la DB de dev ; jamais de DSN en écriture prod dans la config projet.
• Filesystem MCP — Limiter args à la racine projet, pas $HOME ni /.
• API internes — Endpoint staging read-only ; workspace Claude sans .env de production.

Matrice de stratégie et chaînes d'attaque : Exposition minimale des permissions MCP.

Dépannage courant

Questions fréquentes

Quelle différence entre MCP et Function Calling ?

Function Calling déclare des tools dans une requête API, souvent liée au modèle/fournisseur. MCP est une connexion Server persistante et un protocole ouvert — une config, plusieurs clients, écosystème communautaire. MCP ≈ runtime de Function Calling standardisé et interchangeable.

Puis-je écrire mon propre MCP Server ?

Oui. SDK officiels TypeScript (@modelcontextprotocol/sdk), Python, etc. Cas typiques : wiki interne, API ticketing, data lake. Minimum : tools/list et tools/call, stdio — déboguer dans Cursor.

MCP envoie-t-il des données au fournisseur de modèle ?

Les résultats des tools entrent dans le contexte de conversation et partent avec votre requête vers l'API LLM du Host — nécessaire pour l'Agent. MCP ne « télécharge » rien en plus ; le risque = droits accordés au Server. Minimal privilege limite l'exposition.

Quelles sources brancher en premier en 2026 ?

Souvent Context7 (docs) + GitHub (dépôt) + Playwright (navigateur). Backend : Supabase ou DBHub ; Linear/Notion si l'équipe les utilise. Détails : 20 MCP Server recommandés.