Un agent peut déjà travailler dans votre dépôt : rechercher du code, modifier des fichiers, exécuter des commandes et parcourir le Web. Mais il ne peut pas accéder à votre outil de suivi des erreurs, à votre base de données, à vos tickets ni à votre documentation. Tant que ces ressources ne sont pas connectées, il se retrouve bloqué dès qu’il doit sortir de l’éditeur.

Le Model Context Protocol (MCP) est un standard ouvert qui connecte un agent à des outils et données externes. Connectez un serveur MCP et l’agent interroge la base de données au lieu de vous demander le schéma. Il ouvre le ticket au lieu de vous expliquer ce qu’il devrait contenir.

C’est cet accès qui distingue un agent sur lequel votre équipe peut s’appuyer d’un agent qui écrit du code de manière isolée. Il fait de la stratégie MCP pour les agents de codage l’un des premiers sujets que les équipes doivent traiter. Ce guide explique concrètement ce que MCP apporte aux agents de codage, quels serveurs connecter en premier et comment en ajouter un en quelques minutes.

#Pourquoi les agents ont besoin d’un véritable accès aux outils

Le travail ne consiste plus seulement à écrire du code, mais à exécuter toute la boucle autour, et les agents de codage s’appuient déjà sur davantage d’outils pour faire tout cela. Dans notre utilisation, le nombre moyen d’appels d’outils par session a augmenté d’environ 30 % sur une récente période de deux mois, les agents lisant des fichiers, parcourant le code, exécutant des commandes et naviguant sur le Web plus souvent au sein d’une même tâche.

Chacun de ces appels d’outils est un point où soit une intégration existe, soit l’agent se heurte à un mur. MCP transforme chacun de ces appels en connexion opérationnelle plutôt qu’en impasse. Le modèle le plus intelligent au monde ne peut toujours pas vous dire pourquoi le déploiement en préproduction a échoué s’il n’a pas accès à votre outil de suivi des erreurs. Connectez ce même modèle à l’outil de suivi, à la base de données et à la file des tickets, et il peut souvent résoudre l’ensemble du problème, du symptôme à la correction. MCP rend ces connexions portables, de sorte qu’un serveur configuré une seule fois fonctionne dans les agents et interfaces dont votre équipe a besoin.

#Questions avant de vous connecter

Si vous configurez MCP pour un agent de codage pour la première fois, voici les points à clarifier avant de commencer à installer des serveurs.

#Qu’est-ce qu’un serveur MCP ?

Un serveur MCP est un petit adaptateur qui expose un outil ou une source de données (une base de données, une API, un produit SaaS) via le Model Context Protocol, afin que tout agent compatible MCP puisse l’utiliser. Dans une configuration MCP pour un agent de codage, l’agent est le client et le serveur, le connecteur. Les serveurs MCP exposent des capacités comme des outils, des requêtes et des ressources via le protocole. En pratique, vous n’avez pas à en écrire la plupart : le fournisseur en livre un, ou la communauté s’en charge, et vous configurez votre agent pour l’utiliser.

#En quoi MCP se distingue-t-il d’un plugin ou d’une intégration API classique ?

Un plugin est conçu pour une seule application. Une intégration API brute est conçue pour une seule paire de systèmes, et il faut la recréer pour l’agent suivant. MCP constitue la couche standard intermédiaire : un serveur écrit une seule fois fonctionne avec n’importe quel client qui parle le protocole. Connectez Sentry ou Postgres via MCP : cela fonctionne de la même manière dans Cursor comme dans n’importe quel autre client MCP, sans avoir à créer une intégration sur mesure à chaque fois.

#Est-ce que l’agent exécute ces outils de manière autonome ?

Il les appelle dans le cadre de son travail, dans les limites des accès que vous lui accordez. Vous choisissez les serveurs à installer et, pour tout ce qui est sensible, vous vous authentifiez via OAuth afin que le serveur n’accède qu’à ce que votre compte autorise. Les serveurs distants peuvent s’authentifier avec OAuth lorsque le serveur l’exige, ou avec des en-têtes et des clés API ; les serveurs locaux s’exécutent comme des commandes shell sur votre machine. L’agent dispose d’un ensemble d’outils défini, et non d’un chèque en blanc sur vos systèmes.

#Qu’est-ce qui distingue un bon serveur MCP d’un serveur trop bavard ?

Les bons fournissent à l’agent un ensemble limité d’actions aux noms explicites, pour qu’il sache quand s’en servir. Les mauvais déversent des dizaines d’outils à faible valeur dans chaque prompt, encombrant la fenêtre de contexte de descriptions d’outils inutilisées, un problème qui s’accentue à mesure que vous ajoutez des serveurs. Démarrez avec des serveurs pour les systèmes que vous utilisez réellement en cours de tâche : votre base de données, votre outil de suivi des erreurs, tout ce qui vous oblige à passer constamment d’une fenêtre à l’autre, puis n’en ajoutez que lorsqu’un vrai workflow l’exige.

#Meilleurs serveurs MCP pour Cursor, par cas d’usage

Le Marketplace de Cursor répertorie des plugins officiels qui s’installent en un clic et embarquent un serveur MCP (souvent avec des rules et des skills). Voici les serveurs MCP qu’il vaut la peine de connecter en priorité, regroupés par cas d’usage.

Bases de données. Donnez à l’agent un accès en lecture (et, avec précaution, en écriture) à votre schéma et à vos données pour qu’il arrête de deviner comment vos tables sont structurées.

• Supabase : gérer les tables, récupérer la config et interroger les données dans l’ensemble de vos projets Supabase.
• MongoDB : se connecter aux bases de données, explorer les données, gérer les collections et optimiser les requêtes.
• Neon Postgres : gérer les projets et les bases de données Neon via le serveur MCP Neon.
• Prisma : serveur MCP, rules et skills pour le développement de bases de données.

Workflows de développement. Connectez l’agent aux outils où le travail est suivi, livré et supervisé.

• Linear : gérer les issues, les projets et les documents dans l’ensemble de votre workspace Linear.
• Sentry : récupérer erreurs et traces pour permettre à l’agent de déboguer à partir de vrais problèmes de production.
• GitLab : planifier et gérer les issues, les merge requests et les pipelines depuis l’éditeur.
• Datadog : interroger logs, métriques, traces et tableaux de bord via un serveur MCP préconfiguré (en preview).

Remarque : GitHub ne figure pas dans la liste MCP, car il s’agit d’une intégration native à Cursor. La Cursor GitHub app connecte vos repositories depuis le tableau de bord afin que des fonctionnalités comme Agents Cloud et Bugbot puissent agir sur vos pull requests. Vous la connectez une seule fois dans Integrations au lieu de l’ajouter via mcp.json.

Automatisation du navigateur. Laissez l’agent piloter un vrai Browser pour tester, reproduire des bugs et récupérer des données en direct.

• Browserbase Browse : naviguer, cliquer, remplir des formulaires, extraire des données et prendre des captures d’écran, le tout via MCP.
• BrowserStack : tester des sites et des applications mobiles sur de vrais appareils et déboguer les échecs.
• Bright Data : recherche web, extraction de contenu et automatisation du navigateur sur une plateforme de données web.

Récupération de documentation. Gardez l’agent calé sur une documentation à jour et spécifique à chaque version, plutôt que sur des données d’entraînement obsolètes.

• Context7 : faire remonter une documentation à jour, spécifique à une version, ainsi que des exemples de code directement dans le contexte.
• Notion : intégrer la documentation, les spécifications et les exigences de votre équipe au workflow de développement.

Le marketplace en propose bien d’autres (Figma, Stripe, Postman, entre autres), alors parcourez-le pour votre stack. De nouveaux serveurs sont ajoutés régulièrement.

#Comment ajouter un serveur MCP dans Cursor

Deux possibilités : un clic depuis le marketplace, ou un petit fichier de configuration pour tout ce qui est personnalisé.

Un clic. Sur une fiche du marketplace, cliquez sur Add to Cursor pour installer le serveur et vous authentifier avec OAuth. C’est le moyen le plus rapide de connecter les serveurs listés ci-dessus.

Fichier de configuration. Pour un serveur personnalisé ou auto-hébergé, ajoutez-le à mcp.json. Utilisez .cursor/mcp.json dans un projet pour des outils propres au projet, ou ~/.cursor/mcp.json dans votre répertoire personnel pour des outils disponibles partout. Un serveur local (basé sur des commandes) ressemble à ceci :

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

Un serveur distant (HTTP ou SSE) utilise une URL à la place :

{
  "mcpServers": {
    "server-name": {
      "url": "http://localhost:3000/mcp",
      "headers": {
        "API_KEY": "value"
      }
    }
  }
}

Pour les équipes. Les administrateurs peuvent configurer les serveurs MCP de l’équipe une seule fois pour les Agents Cloud depuis le tableau de bord, et associer ces mêmes serveurs à un marketplace d’équipe pour la fenêtre Agents, l’IDE et la CLI. Les membres de l’équipe devront peut-être encore les installer et s’authentifier, mais ils n’ont pas chacun à modifier manuellement mcp.json.

La documentation couvre les transports, l’authentification et la référence complète de la configuration. Rendez-vous sur cursor.com/docs/mcp.

#Créez votre propre serveur MCP

Si aucun serveur n’existe pour votre service interne, vous pouvez en créer un. Écrivez-le dans n’importe quel langage capable d’écrire sur stdout ou d’exposer un endpoint HTTP, et faites-lui exposer un petit ensemble d’outils aux noms explicites qui encapsulent votre API.

Le moyen le plus rapide de démarrer consiste à laisser l’agent s’en charger. Indiquez à Cursor la référence de l’API, la spécification OpenAPI ou la bibliothèque cliente de votre service, puis demandez-lui d’ébaucher un serveur MCP pour les endpoints qui vous intéressent. Il peut lire le schéma, générer le schéma JSON et le gestionnaire de chaque outil, puis configurer l’authentification, afin que vous n’ayez plus qu’à examiner et affiner le résultat plutôt que de partir d’un fichier vierge. Limitez le nombre d’outils, nommez clairement chaque action et ajoutez le serveur à mcp.json comme vous le feriez pour un serveur tiers.

#Intégrez-le à la stack que vous utilisez déjà

Un modèle, à lui seul, peut écrire du code. Un agent de codage avec MCP connecté aux systèmes avec lesquels vous travaillez prend en charge une tâche, du ticket jusqu’au correctif, et vérifie son propre travail au passage. MCP rend ces connexions portables entre les outils que vous utilisez. Choisissez les deux ou trois serveurs qui correspondent à votre stack, connectez-les et donnez à l’agent un accès direct aux systèmes entre lesquels vous ne cessez de basculer.