Minds Team

MCP Workflow Examples for AI Market Research

[fr] Block-first MCP workflows for cohesive multi-question Studies.

These examples assume you have connected the Minds MCP server for ChatGPT, Claude, and Cursor. If not, follow the Minds MCP setup guide first.

Guided Study Confirmation Workflow

For a broader task, multiple questions, a visual asset, structured outputs, or an explicit research method, the assistant follows this sequence:

User request
  -> create_study_plan (draft only)
  -> present captured intent, main source, questions, methods, and outputs
  -> ask every returned confirmation question
  -> revise_study_plan if the user answers or changes anything
  -> explicit user confirmation of the exact revision
  -> start_study_run
  -> get_study_status with the returned runId until collection settles
  -> read_study_summary

Le modèle ne doit pas approuver silencieusement ses propres questions ou méthodes. Gardez les Studies simples quand cela suffit. Consultez list_research_methods : Conjoint et les autres méthodes quantitatives disponibles exécutent leurs plans et calculs enregistrés ; les méthodes avancées exigent un accord explicite. Examinez toute alternative avant confirmation. Pour un asset associé à une question, get_study_heatmap / start_study_heatmap lit ou lance son analyse visuelle distincte. Rapportez uniquement les données retournées.

The original create_study_plan.request is planner input and is not sent verbatim to Minds. The preview labels the exact proposed respondent-visible question text; after confirmation, get_study_run exposes the confirmed or server-prepared question set as a visibility audit. By contrast, treat all text in a direct ask_study.question as respondent-visible input: the system may classify or reformat it, but any part can reach the Minds and influence their answers. Keep planner and MCP-client orchestration notes outside direct questions.

At the execution boundary, a plan_limited response means nothing was started: explain the Study-answer limit and required upgrade. During polling, status: plan_limited means the processor preserved partial answers but stopped the remaining questions at the paywall. Never call either case complete, and never hide it behind a generic error. After an upgrade, use a follow-up run for only the unanswered questions.

Une exécution confirmée est répondue comme un répondant remplit un questionnaire : les questions s'enchaînent dans l'ordre et chaque Mind ne voit que ses propres réponses précédentes dans cette exécution. Des effets d'ordre peuvent donc apparaître comme dans une enquête réelle. Faites tourner l'ordre des questions sur des exécutions séparées lorsque le protocole doit les contrôler. Pour un filtre, donnez à une question un askIf qui désigne une question à choix antérieure et ses options ; les Minds non interrogés sont exclus des résultats de cette question, et une question posée à personne indique not_asked, pas un échec. Après l'exécution, answerConsistency signale les réponses qui contredisent les autres réponses du même Mind. Ces signalements servent à la revue ; les réponses ne sont jamais modifiées.

This lifecycle plans research, not every Study action. A standalone “export this” request routes to export_study. “Show the same result differently” reads the existing Study or summary and changes presentation without queueing new respondents. Only create a new plan when the requested output changes what evidence the Study must collect.

Consumer Research Workflow

A typical workflow for a brand team researching a product launch:

Step 1: Create Consumer Personas

"Create five consumer personas for our skincare launch:
 - 'Lena, 22, Berlin' — Gen Z student, eco-conscious, discovers brands on TikTok
 - 'Maya, 19, London' — retail worker, trend-driven, shops based on peer recommendations
 - 'Aisha, 24, NYC' — junior designer, budget-conscious, cross-references Reddit reviews
 - 'Sarah, 35, Munich' — part-time teacher, mom of two, safety-first buyer
 - 'Jessica, 38, Chicago' — marketing manager, mom, trusts dermatologists over influencers"

Step 2: Organize into Demographic Audiences

"Create an Audience called 'Gen Z Women (18-25)' with Lena, Maya, and Aisha.
Create another Audience called 'Millennial Moms (30-42)' with Sarah and Jessica."

Step 3: Create a Research Study

"Create a Study called 'Sustainable Skincare Launch Study' with both Audiences"

Step 4: Run Survey Questions

"Plan one launch-research question block for the Study with these sections:
1. Price sensitivity: On a scale of 1-10, how likely are you to switch to a sustainable skincare brand if it costs 20% more?
2. Discovery: Where do you typically discover new skincare products?
3. Switching barriers: What would make you stop buying from your current skincare brand?
Show me the complete plan for confirmation, then run all three questions together."

Step 5: Analyze & Export

"Show me the analytics for the Sustainable Skincare Study"

"Export the Study as a PDF report for the brand team"

Valider une Audience

Pour vérifier à quel point les réponses d’une Audience se rapprochent de vraies enquêtes publiées, l’assistant suit cette séquence :

Créer ou choisir une Audience (au moins 10 Minds prêts)
  -> validate_audience (trouve les enquêtes publiées les plus adaptées ou utilise les benchmarkIds indiqués)
  -> get_audience_validation avec batchId jusqu’à ce que status soit completed, failed ou cancelled
  -> lire le score combiné, le score et la plage à 95 % de chaque enquête, et les questions écartées

validate_audience et get_audience_validation sont appelables par leur nom depuis les clients MCP qui appellent directement les outils. Ils ne figurent pas encore dans la découverte d’outils des assistants ; la même fonctionnalité est disponible dès maintenant via l’API v1 et l’onglet Validation de l’Audience.

Une exécution dure généralement de 10 à 60 minutes : l’assistant interroge donc régulièrement le statut au lieu d’attendre un seul appel. Il présente le score de chaque enquête avec sa plage et les personnes interrogées, et laisse visibles les questions écartées avec leurs raisons. Sans batchId, get_audience_validation renvoie la validité globale de l’Audience et les validations incluses restantes ce mois-ci.

Avant de lancer la validation, l’assistant vérifie que l’Audience est stabilisée : readiness.fullyTrained vaut true et la phase de recherche n’est plus researching. Une validation lancée plus tôt évalue l’Audience dans l’état où elle se trouve à ce moment-là. Pendant l’exécution, les Minds répondent à partir de leur profil, sans consulter leurs documents de connaissance ni effectuer de recherche web. En présentant un score, l’assistant précise qu’il s’agit de 100 moins l’écart absolu moyen par option de réponse, et non d’une part de bonnes réponses : un score élevé peut donc masquer un écart important sur une option. Les parts humaines et synthétiques par question ainsi que le plancher de bruit sont disponibles via l’API v1.

Pour un résultat portant sur une population partielle, l’assistant doit lire respondentScope avant de décrire la correspondance. Une enquête infirmière pourrait par exemple retenir 12 Minds parmi les 16 professionnels de santé d’une Audience. Présente le pourcentage avec « 12 Minds sur 16, personnel infirmier » ; ne le décris pas comme la validité de tous les professionnels. Les réserves distinguent l’appartenance confirmée par la cohorte, celle étayée par d’autres éléments du profil, les cas incertains et les incompatibilités explicites.

L’admissibilité est évaluée avant la collecte des réponses, indépendamment de celles-ci. Des éléments individuels peuvent combler les lacunes de cohorte ; les distributions agrégées ne prouvent pas l’admissibilité personnelle. Seuls les membres confirmés ou étayés participent, avec un minimum de dix. Si ce seuil n’est pas atteint, explique pourquoi l’enquête n’a pas été menée. La correspondance résulte d’un calcul numérique, tandis que le modèle effectue la sélection. Les coûts suivent les répondants sélectionnés et le score global omet les sous-ensembles. Limite l’interprétation à cette Audience, même si certains Minds appartiennent aussi à une autre.

Exemple de prompt :

"Valide mon Audience 'German SaaS buyers' avec des enquêtes publiées et dis-moi à quel point elle s’en rapproche."

Use Cases

Product Concept Testing

Create Studies with target consumer Audiences to test product concepts, packaging, and naming before investing in production. Compare reactions across Audiences instantly.

Pricing Research

Survey synthetic consumers on willingness to pay at different price points. Identify the sweet spot where value perception meets margin targets.

Brand Perception Audit

Build Studies containing your target Audiences. Ask about brand awareness, trust, and purchase intent in one cohesive question block. Compare your brand against competitors through consumer eyes.

Campaign Message Testing

Test ad copy, taglines, and visual concepts with synthetic target audiences before committing media spend. Identify which messages resonate with which segments.

Market Entry Research

Entering a new market? Create consumer personas for the target region and test product-market fit, cultural sensitivities, and channel preferences.

Example Conversations

Quick Consumer Insight

You: "I need to understand how Gen Z and millennials in Europe feel about subscription-based skincare. Create one Audience for each segment and plan one cohesive Study asking what would convince them to subscribe."

AI Assistant: Drafts the Minds and audience structure, creates a Study, presents the exact proposed research question(s), and requests confirmation when the request expands into a broader Study. After execution, it reports the actual returned grouped responses without pre-writing a conclusion.

Expert Consultation

You: "Talk to my Brand Strategy expert about positioning a premium organic baby care line in the German market."

AI Assistant: Uses chat_with_mind to query the expert Mind and presents its actual response, preserving any returned citations. It labels the output as synthetic expert perspective rather than independent legal or regulatory advice.

Competitive Analysis

You: "Create a Study with 'Loyal Customers' Audiences for our top 3 competitors. Plan one block asking what they love most about their current brand and what frustrates them."

AI Assistant: Creates private synthetic Audiences, confirms the comparative multi-question research plan, runs the Study once, and reports only differences supported by the returned responses and calculations.

Automation guardrails

  • Keep new Audiences and Studies private unless the user explicitly requests a public link.
  • Planning does not start research. Confirm the exact latest revision before start_study_run.
  • Poll status tools instead of treating a timeout or elapsed duration as completion.
  • Require explicit confirmation immediately before lifecycle deletion actions.
  • Preserve citations, resource IDs, workspace/shared links, and download links exactly.
  • Treat plan_limited before execution as “nothing started” and status: plan_limited during execution as partial, preserved work.
  • Use list_research_methods before promising a named method; only executable: true is runnable.
  • Do not infer customer findings in advance. The example prompts in this guide describe workflows, not guaranteed conclusions.

For a full routing and safety contract, see the MCP operating guide for agents.

Une collecte peut se terminer avec status: "partial" lorsqu’une question ou la réponse d’un Mind manque. Arrêtez l’interrogation périodique à cet état terminal et expliquez le manque, sans présenter le résultat comme complet. progress.pct mesure les questions terminées, pas la couverture des répondants. Les nouveaux résultats conservent outputData.responseCoverage avec expected, received et les associations Audience/Mind manquantes. progress.partial compte les questions dont la couverture est incomplète. L’absence de ces données dans un ancien résultat ne prouve pas que tous ont répondu. Conservez les réponses brutes valides et leurs résultats sans modification; examinez les éléments manquants avant une nouvelle tentative séparée.

Attendre la disponibilité puis poursuivre

Dans ChatGPT Work sur le web, ou Work avec Cloud sur ordinateur, demandez à Minds un avis lorsqu’une Audience est prête ou qu’une Étude confirmée se termine. Une Étude déjà approuvée peut continuer dès que l’Audience est prête. Vérifiez et confirmez d’abord le brouillon d’Audience et le plan : la demande initiale n’approuve pas un plan jamais vu, et un événement n’autorise ni questions, ni exécutions, ni dépenses supplémentaires. L’hôte choisit le canal ; un SMS n’est pas garanti.

L’événement d’Audience attend que ses Minds soient utilisables ; un aperçu en attente de validation n’est pas prêt. Celui d’Étude attend la synthèse enregistrée. Réponses incomplètes, résumé provisoire, échec, annulation et limites du forfait sont signalés par ready=false. Relisez l’exécution originale avec get_study_status({ study: { id: studyId }, runId }) et conservez ses identifiants ; ne la soumettez jamais à nouveau à la réception d’un événement.

Les abonnements durent au plus 24 heures et doivent être renouvelés avant refreshBefore. Clés de signature et URL de rappel sont chiffrées au repos. Chaque livraison revérifie la connexion, les règles du compte et l’accès à la ressource. Les états en attente sont vérifiés chaque minute ; vérification et nouvelles tentatives peuvent ajouter un délai. Aucun historique n’est rejoué. En cas d’échec d’inscription, gardez le lien vers l’espace de travail et consultez l’état ; ne promettez un avis qu’après inscription réussie.

Nommez la tâche de suivi d'après la recherche et l'étape demandée, sans promettre un succès avant de connaître le résultat. Les notifications doivent utiliser la langue de l'utilisateur et commencer par le résultat et le nom de la recherche, immédiatement suivis du lien vers l'espace de travail et de l'action suivante. Ce début doit être compréhensible seul : les aperçus des e-mails ChatGPT peuvent tronquer le message complet. Ajoutez une brève conclusion et le nombre de répondants ou de questions uniquement lorsque les résultats enregistrés les confirment. Omettez les noms d'événements, identifiants internes et champs JSON des notifications ordinaires de fin, sauf demande explicite.

Si un brouillon attend une confirmation, indiquez « prêt à être examiné » et que la recherche n'a pas commencé ; conservez l'ID exact, la révision et les questions de confirmation dans la conversation complète de validation. En cas d'échec ou de résultat partiel, consultez get_audience_creation_progress({ operationId }) ou get_study_status({ study: { id: studyId }, runId }) pour l'opération d'origine. Expliquez la cause renvoyée, l'avancement enregistré, ce qui manque et l'action suivante possible ; si aucune cause n'est disponible, dites-le. N'inventez pas de raison et ne relancez pas automatiquement la recherche. Notifiez uniquement les étapes demandées ; poursuivez les étapes intermédiaires déjà autorisées sans autre notification, sauf si une validation est nécessaire ou si le travail est bloqué. L'hôte contrôle le modèle d'e-mail et les canaux : un bouton direct dans l'e-mail ou un SMS ne peut donc pas être promis.

audience.creation.finished → operationId · study.run.finished → studyId, runId