MCP Cursor : installer, configurer et connecter Cursor à Supabase, API et search

Si tu veux que Cursor écrive du code qui colle à tes données, tes services et ta documentation, MCP Cursor est l’approche la plus directe. C’est aussi une base solide pour du vibe codding, mais avec des outils et un context fiables (Supabase, API, search) pour éviter le code approximatif.
‍

MCP Cursor en 2 minutes : ce que c’est et pourquoi ça change ton travail

MCP signifie Model Context Protocol. L’idée est simple : dans ton IDE Cursor, tu connectes un serveur MCP qui expose des outils. Ensuite, le model d’IA peut appeler ces outils pendant le développement. Au lieu de “deviner”, il peut lire un context, interroger une API, faire du search, ou récupérer des données utiles. 

Dans la pratique, MCP Cursor te permet de :

• Relier Cursor à Supabase pour explorer les tables, comprendre le schéma, et générer du code cohérent avec tes data.
• Ajouter un serveur MCP de search (Brave, par exemple) pour retrouver la bonne documentation et vérifier une version.
• Rendre le flux de codage plus fiable : moins d’allers retours, moins de code “hors sol”, plus de test et de validation.

Si tu ne dois retenir qu’une chose : MCP Cursor, c’est le pont propre entre ton IDE et tes services.

‍

Démarrer vite : install et première configuration MCP dans Cursor

Le chemin le plus rapide consiste à ajouter un serveur MCP, puis à vérifier qu’il apparaît dans Cursor. Cursor lit une configuration JSON, souvent placée dans un fichier mcp.json. La doc Cursor indique une configuration globale via ~/.cursor/mcp.json pour rendre les outils disponibles partout. 

Où mettre le fichier de configuration

Commence simple : mets la configuration en global.

• macOS / Linux : ~/.cursor/mcp.json
• Windows : le principe est le même, un fichier mcp.json dans le dossier de config Cursor

Cursor documente ce fichier comme point d’entrée principal. 

Tu peux aussi vouloir une config par projet, surtout pour la collaboration. Certains utilisent .cursor/mcp.json. Selon les versions, il peut y avoir des cas où le fichier local n’est pas pris en compte. Si tu as un doute, repasse en global pour valider que tout marche.

Vérifier que MCP est bien actif dans l’IDE

Une fois ton serveur MCP ajouté, va dans Cursor :

Settings, puis Cursor Settings, puis Tools & MCP.

C’est l’endroit où tu vois les serveurs, leur état, et les outils disponibles. Après une autorisation, un redémarrage peut être nécessaire pour que Cursor détecte toutes les fonctionnalités. 

‍

MCP Cursor avec Supabase : la connexion la plus utile pour coder avec tes données

Si tu utilises Supabase, MCP te donne un avantage immédiat : Cursor n’a plus besoin d’inventer la structure de ta base. Il peut s’appuyer sur le schéma, les tables, et des infos fiables côté documentation. C’est exactement le type de context qui améliore un flux de development.

Configurer le serveur MCP Supabase dans Cursor

Supabase fournit un guide MCP et indique comment vérifier la connexion dans Cursor (Tools & MCP). 

Dans ton ~/.cursor/mcp.json, tu peux commencer avec une configuration très simple. L’exemple ci-dessous te donne une base claire. Adapte le nom si tu veux.

{

  "mcpServers": {

    "supabase": {

      "url": "https://mcp.supabase.com/mcp"

    }

  }

}

‍

Ensuite, relance Cursor si besoin, puis retourne dans Tools & MCP pour vérifier que le serveur est connecté. Supabase recommande aussi de tester en langage naturel, par exemple en demandant au model de lister les tables via les outils MCP. 

Scoper l’accès Supabase pour rester propre et serein

Quand tu branches un IDE à des services, la configuration doit rester stricte. C’est vrai pour Supabase, surtout si tu veux éviter un mauvais appel sur un mauvais environnement.

Voici une règle simple : commence en lecture seule, sur un projet de dev ou de test. Puis élargis si tu as une bonne raison.

Supabase met en avant le fait que la connexion passe par une autorisation, et que l’état est visible dans le client MCP (comme Cursor).

Dans ton processus, pense comme un dev :

Tu configures, tu testes, tu valides, puis tu itères. Tu ne “branches pas tout” d’un coup.

Comment utiliser Supabase MCP au quotidien dans Cursor

L’objectif n’est pas d’empiler des commandes. L’objectif est d’améliorer ton codage, étape par étape, avec des outils fiables.

Un flux très efficace ressemble à ça :

Tu commences par demander au model d’IA de récupérer le schéma, puis tu lui demandes de générer le code côté app, puis tu le forces à écrire des tests.

Exemples de prompts simples, orientés travail :

• “Liste les tables et les relations. Utilise les outils MCP Supabase.”
• “Propose les types TypeScript pour ces data, puis génère le code d’accès.”
• “Écris un test d’intégration et une requête SQL de validation.”

Ce qui change ici, c’est le context. Cursor peut s’appuyer sur tes données. Le code devient plus juste, plus vite.

‍

Ajouter un serveur MCP de search Brave pour une documentation web à jour

Même avec Supabase, tu vas souvent devoir chercher une info de docs, une version, un paramètre d’API, ou une option de configuration. Un serveur MCP de search sert exactement à ça.

Brave propose un serveur MCP open source, avec une variable BRAVE_API_KEY obligatoire. Il supporte aussi plusieurs modes de transport, dont stdio et http.

Pourquoi c’est utile dans Cursor

Cursor est très bon pour écrire du code. Mais sur une doc qui bouge vite, le search reste un point clé.

Avec Brave MCP :

• Tu retrouves la bonne documentation web sans quitter ton IDE.
• Tu réduis les erreurs de version.
• Tu peux demander au model de citer ou de résumer la doc trouvée, puis d’adapter ton code.

C’est une bonne habitude pour tout ce qui touche à une API, une config, ou un changement récent.

Installer Brave MCP et le configurer dans mcp.json

Le dépôt Brave indique les variables supportées, dont BRAVE_API_KEY, et précise un transport par défaut en stdio. 

Côté Cursor, tu peux déclarer un serveur MCP “command” via Node. Tu peux aussi éviter de mettre une clé en clair en passant par une variable d’environnement. Cursor documente l’usage de variables dans mcp.json.

Exemple de configuration simple, en stdio :

{

  "mcpServers": {

    "supabase": {

      "url": "https://mcp.supabase.com/mcp"

    },

    "brave-search": {

      "command": "npx",

      "args": ["-y", "@brave/brave-search-mcp-server"],

      "env": {

        "BRAVE_API_KEY": "${BRAVE_API_KEY}"

      }

    }

  }

}

‍

Ensuite, tu définis BRAVE_API_KEY dans ton environnement local, puis tu relances Cursor. L’idée est d’avoir une configuration stable, versionnable, et sans fuite de secrets.

Tester rapidement la partie search

Pour valider, fais trois tests simples dans Cursor :

D’abord une requête de documentation, comme “Trouve la doc officielle de X, puis résume les options utiles”.

Ensuite une requête de version : “Vérifie la version actuelle, et donne les breaking changes”.

Enfin un test orienté code : “Cherche un exemple d’usage de l’API, puis adapte le snippet à mon code”.

Si ces trois points passent, ton serveur MCP Brave est exploitable dans ton flux.

‍

Comment MCP fonctionne vraiment dans Cursor : le minimum à comprendre

Tu n’as pas besoin de connaître toute la théorie pour être efficace, mais tu dois connaître trois notions : serveur, outils, transport.

Un serveur MCP expose des outils. Cursor agit comme client. Le model peut ensuite appeler ces outils dans l’IDE, au moment où il en a besoin, pendant le développement.

Tools, resources, prompts : pourquoi on s’y retrouve vite

Selon les implémentations, un serveur MCP peut exposer :

Des tools, qui sont des actions, comme “faire un search”, “lister des tables”, “exécuter une requête”.

Des resources, qui sont des ressources consultables.

Parfois des prompts ou des helpers, selon le SDK et le serveur.

Dans la vraie vie, tu t’en sers pour deux choses : récupérer du context fiable, puis produire du code qui colle à ce context.

Le choix du transport : stdio ou HTTP

Le transport, c’est la façon dont Cursor parle au serveur MCP.

En local, stdio est très courant et simple. Il passe par l’entrée et la sortie standard du process. C’est pratique pour un outil Node lancé en commande.

Pour des services distants, tu peux passer par des variantes HTTP. Certaines docs indiquent que SSE a existé et peut encore être supporté, mais des sources récentes mentionnent que le standard évolue et recommande surtout stdio, avec un HTTP de type streaming pour certains cas. 

Mon conseil : commence en stdio pour tes outils locaux et ton search. Et utilise une URL HTTPS quand le provider propose un serveur géré, comme Supabase.

‍

Un flux de développement qui marche : Supabase, code, tests, puis docs

Le vibe codding marche quand le flux est court, mais il devient puissant quand MCP apporte les bons outils, données et docs au bon moment.

Le meilleur usage de MCP Cursor, c’est un processus clair. Pas une démo. Pas un gadget.

Voici un guide de travail simple, que tu peux répéter sur chaque fonctionnalité.

Étape 1 : cadrer la donnée avant d’écrire du code

Tu demandes au model de récupérer le schéma et les contraintes. Tu valides ce que tu lis.

Tu peux ensuite lui demander de reformuler les données sous forme de types, ou d’objets de domaine. Tu obtiens un code plus propre, plus stable.

Étape 2 : générer l’accès data et les fonctions côté API

Avec Supabase, tu peux produire :

Des requêtes de lecture.

Des filtres.

De la pagination.

Des fonctions de service, avec une signature claire.

À ce stade, tu insistes sur la clarté. Tu veux du code simple. Tu veux des noms stables. Tu veux des fonctions testables.

Étape 3 : écrire un test qui prouve que la fonctionnalité marche

C’est ici que MCP Cursor devient très rentable.

Tu demandes au model :

D’écrire un test unitaire sur la logique.

Puis un test d’intégration qui vérifie la requête ou l’API.

Puis une check list courte des cas limites.

Ce trio améliore ton flux. Et ça réduit le temps perdu à “deviner” d’où vient un bug.

Étape 4 : mettre à jour la documentation et les docs internes

Quand le code est bon, tu veux des docs utiles :

Un README court, orienté usage.

Une section “configuration” qui décrit les variables.

Un rappel des commandes de test.

Tu utilises le search Brave si tu dois citer une doc web ou vérifier un paramètre.

‍

Sécurité et configuration : garder le contrôle quand tu connectes des services

MCP rend les outils puissants. Donc ta configuration doit rester propre.

Le point le plus important est de limiter l’accès.

Tu évites de brancher la prod tant que tu n’as pas un processus clair. Tu préfères un projet de test. Tu utilises des droits minimaux. Tu limites ce qui est possible, surtout au début.

Supabase souligne que l’autorisation et la détection des outils peuvent nécessiter un redémarrage et une vérification dans le client. Ça rappelle un point clé : ces connexions sont réelles, et elles doivent être traitées comme une intégration. 

Côté Brave, garde ta clé hors du fichier. Passe par une variable d’environnement. Le serveur Brave supporte explicitement BRAVE_API_KEY.

‍

Diagnostiquer un MCP qui ne répond pas dans Cursor, sans perdre une heure

Quand ça bloque, ce n’est presque jamais “mystique”. C’est souvent la configuration, la commande, ou l’autorisation.

Commence par ces questions simples.

Le fichier mcp.json est il au bon endroit, et bien formé en JSON.

Le serveur se lance t il vraiment. Pour un serveur en command, est ce que Node et npx sont disponibles.

Les variables d’environnement sont elles présentes, surtout pour Brave.

Dans Cursor, est ce que le serveur apparaît dans Tools & MCP, et est il connecté.

Si tu as mis une config au niveau projet et que Cursor ne la lit pas, essaie la config globale ~/.cursor/mcp.json pour isoler le problème. Des retours de communauté vont dans ce sens sur certaines versions. 

‍

Collaboration : rendre MCP Cursor utile en équipe

MCP Cursor n’est pas seulement un outil perso. Bien configuré, il aide une équipe à produire du code plus cohérent.

L’idée est d’avoir un processus simple :

Une configuration partagée, quand c’est possible.

Des instructions de docs internes, pour que tout le monde configure de la même façon.

Un protocole de test, pour valider qu’un serveur MCP répond.

Concrètement, tu peux documenter :

Comment installer Cursor.

Où mettre la configuration.

Comment configurer Supabase, quels services sont autorisés.

Comment configurer Brave, et où placer la clé.

Quelles commandes de test lancer après une mise à jour.

Tu réduis la friction. Tu améliores le travail. Et tu rends le development plus fluide.

‍

MCP Cursor : ce que tu peux faire ensuite pour aller plus vite et écrire mieux

Une fois Supabase et Brave en place, tu peux étendre MCP vers d’autres services :

Un serveur MCP pour ton design system, afin de récupérer la documentation interne.

Un serveur MCP pour ton backlog, afin de lier le codage aux tickets.

Un serveur MCP pour un outil de monitoring, afin de corréler erreurs et changements de version.

Tu n’es pas obligé de tout faire. Le bon critère est simple : est ce que ça améliore ton flux, et est ce que ça réduit les erreurs.

MCP Cursor est un guide de discipline autant qu’un guide d’outils.

‍

Aller plus loin avec Scroll

Si tu veux mettre MCP Cursor en place proprement, avec une configuration solide, un flux de test, et une intégration Supabase adaptée à ton produit, l’agence Scroll peut t’aider. On intervient souvent sur des sujets de transformation digitale et d’IA dans l’IDE : choix des serveurs MCP, configuration, sécurité, documentation, et mise en place d’un processus de développement qui tient dans la durée.

‍