Construire un agent de recherche marketing dans Cursor avec Minds MCP

Ce guide est pour quelqu'un qui veut construire un agent de recherche marketing custom plutôt que d'en utiliser un sur étagère. Le résultat final est un agent dans Cursor qui prend un brief de recherche en langage naturel, tire des analytics produit depuis PostHog, lance une Study synthétique avec Minds, croise les deux et poste un résumé sur Slack. Environ 90 minutes de travail de bout en bout si vous avez déjà des comptes sur les trois services.

L'idée n'est pas de shipper un produit poli. C'est de rendre la boucle agentique concrète : l'agent reçoit un brief, l'agent appelle plusieurs serveurs MCP en séquence, l'agent raisonne sur le résultat conjoint, l'agent rapporte. Une fois que vous en avez construit un, le pattern se transpose à tout ce que vous voulez construire d'autre.

Prérequis

Trois comptes et trois clés API :

• Un compte Minds avec une clé API (minds_…). Inscrivez-vous sur getminds.ai si vous n'en avez pas.
• Un compte PostHog avec une clé API personnelle.
• Un workspace Slack où vous pouvez poster sur un canal via un webhook ou un app token.

Une installation de Cursor (ou n'importe quel éditeur avec support MCP : VS Code avec Copilot fonctionne pareil).

Environ 30 minutes de temps de configuration concentré, puis 60 minutes d'itération sur le brief et le prompt de l'agent.

Étape 1 : connecter les trois serveurs MCP

Chacun des trois services expose un serveur MCP. On va connecter les trois à Cursor.

Dans Cursor, ajoutez les trois serveurs à ~/.cursor/mcp.json (ou à .cursor/mcp.json dans le projet).

Minds. Ajoutez le serveur Minds MCP pour la recherche marché sous la forme "minds": { "url": "https://getminds.ai/mcp" } et connectez-vous via OAuth lorsque Cursor vous y invite ; aucune clé API n'est nécessaire. Les outils Minds exposés (create_audience_from_brief, ask_audience, create_study, plan_study_questions, export_study et d'autres) apparaissent dans votre tool picker. Pour les étapes par client, utilisez le guide de configuration Minds MCP.

PostHog. PostHog shippe son propre serveur MCP. La configuration recommandée est l'endpoint distant à https://app.posthog.com/mcp, également avec OAuth. Vous obtenez 55 outils couvrant événements, funnels, cohorts et dashboards.

Slack. Le serveur MCP Slack est disponible via npm. Ajoutez-le comme serveur stdio avec npx -y @modelcontextprotocol/server-slack et votre Slack bot token dans le env. Deux outils suffisent : slack_post_message et slack_list_channels.

Redémarrez Cursor. Les trois serveurs devraient apparaître dans la liste d'outils de l'agent. Testez chacun en demandant à l'agent de lister les Audiences (Minds), les cohorts (PostHog) et les channels (Slack).

Étape 2 : choisir un workflow de recherche qui mérite d'être automatisé

L'agent n'est aussi utile que le workflow que vous lui donnez. Choisissez quelque chose de spécifique. L'exemple qu'on va construire :

Prends un nom de feature, trouve les utilisateurs qui ont utilisé la feature dans les 30 derniers jours dans PostHog, caractérise-les comme Audience synthétique via Minds, demande à cette Audience pourquoi elle recommanderait ou non la feature, et poste un résumé dans #product-research sur Slack.

Ce pattern (ancrage avec des données réelles plus enrichissement synthétique plus distribution à l'équipe) est réutilisable à travers de nombreuses décisions. Remplacez-le par le vôtre.

Étape 3 : écrire le prompt de l'agent

Mettez le prompt de l'agent dans un fichier .cursorrules Cursor ou comme system message de votre session d'agent. La structure qui marche :

You are a marketing research agent. Your job is to take a feature name as input
and return a recommendation summary, posted to Slack.

For each request, do the following in order:

1. Use PostHog tools to find users who triggered the feature event in the last
   30 days. Get a count and basic properties (plan tier, account age, region).

2. Build a Minds Audience that matches the dominant cohort from step 1. Use
   `create_audience_from_brief` with a brief that captures the cohort's plan
   tier, tenure, and likely role, and follow it with
   `get_audience_creation_progress`.

3. Ask that Audience one question with `ask_audience`, then read the answers
   with `get_study_status`. Ask: "Would you recommend this feature to a
   colleague? Why or why not? What would have to change for it to be a yes?"

4. Cross-reference the Audience's answers against the PostHog data. Look for
   alignment (do the stated reasons match the actual usage patterns?) and gaps
   (do the answers surface concerns the metrics don't show?).

5. Post a summary to #product-research in Slack with three sections:
   - Cohort profile (who used it)
   - Audience verdict (recommend or not, top stated reasons)
   - Recommended action (what to do next)

Keep the Slack summary under 500 words. Link back to the full Study export.

Ce prompt fait trois choses délibérément :

• Il ordonne les étapes de manière stricte pour que l'agent ne prenne pas de raccourcis.
• Il dit à l'agent comment composer les résultats à travers les outils, pas seulement comment les appeler.
• Il borne la sortie pour que le message Slack soit effectivement lisible.

Étape 4 : tester contre une feature réelle

Choisissez une feature que votre produit a vraiment shippée. Lancez l'agent. La séquence attendue :

1. L'agent appelle une query events PostHog pour feature_used filtrée sur le nom de la feature et les 30 derniers jours. Renvoie un compte et un échantillon.
2. L'agent appelle cohorts PostHog pour caractériser les utilisateurs. Identifie le plan tier dominant et l'âge moyen de compte.
3. L'agent appelle create_audience_from_brief Minds avec un brief comme "Clients payants mid-tier, 6 à 18 mois sur la plateforme, utilisateurs principaux de catégorie de feature" puis suit la création avec get_audience_creation_progress.
4. L'agent appelle ask_audience Minds avec la question de recommandation, ce qui crée une Study privée pour cette Audience.
5. L'agent appelle get_study_status Minds jusqu'à ce que les réponses soient complètes.
6. L'agent lit les réponses. Appelle export_study Minds pour sauvegarder la Study complète pour le lien Slack.
7. L'agent appelle slack_post_message Slack avec le résumé structuré et le lien d'export.

Temps de bout en bout : 60 à 120 secondes selon la taille du cohort et la longueur des réponses, plus le temps de création de l'Audience lors du premier run. L’accès MCP est inclus dans Minds. La recherche Pay as you go consomme des réponses achetées ; les forfaits payants utilisent leur quota applicable. Les frais distincts du fournisseur de modèles dépendent du modèle choisi et de son utilisation.

Si une étape échoue, l'agent retentera généralement une fois ou pivotera. S'il se coince, la cause la plus commune est un prompt fragile à l'étape 4 (le brief d'Audience ne correspond pas proprement au cohort). Réécrivez le prompt du brief pour être plus flexible et relancez.

Étape 5 : le planifier

L'agent ne génère de la valeur que s'il tourne sans vous. Deux chemins :

Trigger manuel via Slack. Ajoutez une commande slash /research [nom-feature] qui déclenche l'agent Cursor. C'est le chemin le plus simple et il marche pour la recherche ad-hoc.

Trigger cron. Utilisez un workflow CI (GitHub Actions, automation Linear, n'importe quoi qui peut tourner sur un planning) pour envoyer une liste de noms de features à l'endpoint d'agent chaque lundi. L'agent lance le workflow une fois par feature et poste chaque résumé. L'équipe reçoit un digest de recherche du lundi matin sans overhead humain.

C'est sur le chemin cron que la valeur s'accumule. Une équipe qui lance de la recherche au niveau feature sur chaque feature shippée pendant un trimestre apprend plus sur son produit qu'une équipe qui lance une grosse étude par an, et à moins de 5 pour cent du coût.

Où les agents custom battent ceux sur étagère

L'argument pour construire ceci plutôt que d'utiliser un outil de recherche packagé :

Spécificité de workflow. Les outils sur étagère optimisent pour le cas le plus commun. Le workflow de recherche de votre équipe est rarement le cas le plus commun. Un agent custom colle exactement à votre rythme de décision.

Composition d'outils. Les mouvements intéressants se passent quand la recherche synthétique est ancrée contre des données produit réelles, puis distribuée dans le canal de votre équipe. Aucun outil sur étagère ne fait la chaîne complète. Un agent custom enchaînant trois MCPs si.

Contrôle de coût. Vous payez par appel, par service. Pas de licences par siège, pas de frais de plateforme par-dessus. L'usage lourd revient moins cher que les outils packagés à l'échelle d'équipe ; l'usage léger est essentiellement gratuit.

Vélocité d'itération. Changer le workflow c'est changer le prompt. Pas de roadmap fournisseur, pas de demandes de feature. La contrainte est votre propre attention, pas le cycle de release de quelqu'un d'autre.

Pièges communs

Quelques arêtes vives tirées de la production :

• Drift d'Audience à travers les appels. Si vous construisez une nouvelle Audience à chaque run, sa composition se déplace subtilement à chaque fois. Construisez l'Audience une fois (cachez l'ID) et réutilisez-la. Le MCP Minds expose list_audiences pour exactement ça.
• Timeouts de query PostHog. Les gros cohorts font timeout l'agent. Plafonnez la taille du cohort dans le prompt ou pré-filtrez à un échantillon représentatif.
• Limites de taille de message Slack. Slack tronque les messages au-dessus de 4000 caractères. Le plafond de 500 mots dans le prompt est largement en dessous, mais si l'agent l'ignore, postez en thread plutôt qu'en message unique.
• Rotation de tokens OAuth. Les trois services font tourner les tokens périodiquement. Si l'agent s'arrête soudain de fonctionner, ré-autorisez chaque connecteur avant de débugger le prompt.

Vers où ça va

Le workflow de recommandation single-feature est le point de départ. Une fois qu'il marche, le même agent généralise à :

• Boucles hebdomadaires d'efficacité de campagne (lancer des réactions synthétiques aux annonces avant que la campagne ne parte en live, valider contre le click-through réel après)
• Positionnement concurrentiel mensuel (lancer des Studies synthétiques contre la messagerie du concurrent, croiser avec vos propres données de conversion)
• Refresh trimestriel des Audiences (mettre à jour les Audiences synthétiques selon les évolutions observées du comportement produit)

Chacune a la même forme : ancrage avec données réelles, enrichissement synthétique, distribution à l'équipe. Construisez le premier. Le reste sont des variations.

Pour plus sur ce qui mérite d'être connecté à côté, voir les meilleurs serveurs MCP pour les agents marketing et recherche en 2026. Pour la catégorie sous-jacente, voir la recherche marché agentique, définie. Pour la question de confiance sur la sortie synthétique, voir valider la sortie de recherche agentique.