Minds Team

MCP Workflow Examples for AI Market Research

[de] 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

Der Assistent darf seine eigenen Fragen oder Methoden nicht stillschweigend genehmigen. Halte einfache Studies einfach. Prüfe list_research_methods: Conjoint und die anderen verfügbaren quantitativen Methoden führen ihre registrierten Designs und Berechnungen aus; fortgeschrittene Methoden benötigen ausdrückliches Opt-in. Prüfe Alternativen vor der Bestätigung. Für ein bereits einer Study-Frage zugeordnetes Asset liest oder startet get_study_heatmap / start_study_heatmap die separate visuelle Analyse. Berichte nur zurückgegebene Evidenz.

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.

Ein bestätigter Lauf wird so beantwortet, wie eine befragte Person einen Fragebogen beantwortet: Die Fragen laufen in ihrer Reihenfolge, und jeder Mind sieht nur seine eigenen früheren Antworten in diesem Lauf. Daher können Reihenfolgeeffekte entstehen wie in einer echten Befragung. Rotiere die Reihenfolge über getrennte Läufe, wenn das Design sie kontrollieren muss. Für Filterführung gibst du einer Frage askIf mit einer früheren Auswahlfrage und deren Optionen; nicht gefragte Minds fließen nicht in die Ergebnisse dieser Frage ein, und eine Frage, die niemandem gestellt wurde, meldet not_asked statt eines Fehlers. Nach dem Lauf markiert answerConsistency Antworten, die anderen Antworten desselben Minds widersprechen. Die Markierungen dienen der Prüfung; die Antworten werden nie geändert.

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"

Eine Zielgruppe validieren

Um zu prüfen, wie nah die Antworten einer Zielgruppe an echten, veröffentlichten Umfragen liegen, geht der Assistent so vor:

Zielgruppe erstellen oder auswählen (mindestens 10 einsatzbereite Minds)
  -> validate_audience (findet die am besten passenden veröffentlichten Umfragen oder nutzt die angegebenen benchmarkIds)
  -> get_audience_validation mit batchId, bis status completed, failed oder cancelled ist
  -> kombinierten Wert, Wert und 95-%-Spanne jeder Umfrage sowie die ausgelassenen Fragen lesen

validate_audience und get_audience_validation sind für MCP-Clients, die Tools direkt aufrufen, per Name verfügbar. In der Tool-Erkennung der Assistenten sind sie noch nicht gelistet; dieselbe Funktion steht schon jetzt über die v1 API und den Tab Validierung der Zielgruppe bereit.

Ein Durchlauf dauert meist 10 bis 60 Minuten, daher fragt der Assistent den Status regelmäßig ab, statt auf einen einzigen Aufruf zu warten. Er berichtet den Wert jeder Umfrage mit ihrer Spanne und dem Kreis der Befragten und hält ausgelassene Fragen samt Grund für die Nutzer sichtbar. Ohne batchId liefert get_audience_validation die Gesamtvalidität der Zielgruppe und die in diesem Monat verbleibenden inklusiven Validierungen.

Vor dem Start prüft der Assistent, ob die Zielgruppe fertig ist: readiness.fullyTrained ist true und die Recherchephase ist nicht mehr researching. Eine früher gestartete Validierung bewertet die Zielgruppe in ihrem Zustand zu diesem Zeitpunkt. Während des Durchlaufs antworten die Minds aus ihren Profilen, ohne ihre Wissensdokumente abzurufen oder im Web zu suchen. Beim Bericht eines Werts erklärt der Assistent, dass der Wert 100 minus die mittlere absolute Abweichung je Antwortoption ist und kein Anteil richtiger Antworten; ein hoher Wert kann daher eine große Abweichung bei einer einzelnen Option verdecken. Menschliche und synthetische Anteile je Frage sowie die Rauschgrenze liefert die v1-API.

Bei einem Ergebnis für eine Teilpopulation muss der Assistent vor der Beschreibung des Werts respondentScope lesen. Eine Pflegeumfrage könnte beispielsweise 12 Minds aus einer Audience mit 16 Beschäftigten im Gesundheitswesen auswählen. Nenne den Prozentwert zusammen mit „12 von 16 Minds, Pflegekräfte“; stelle ihn nicht als Validität aller Beschäftigten dar. Die Hinweise unterscheiden durch Kohortendaten bestätigte Zugehörigkeit, durch weitere Profilbelege gestützte Zugehörigkeit, unklare Fälle und ausdrückliche Widersprüche.

Die Eignung wird vor der Antworterhebung und unabhängig von den Antworten geprüft. Individuelle Belege können Kohortenlücken schließen; aggregierte Verteilungen beweisen keine persönliche Eignung. Nur bestätigte oder belegte Mitglieder nehmen teil, mindestens zehn. Wird diese Zahl nicht erreicht, erkläre, weshalb keine Befragung stattfand. Der Wert entsteht durch numerischen Vergleich, während das Modell die Auswahl übernimmt. Die Kosten richten sich nach den tatsächlich ausgewählten Befragten; Teilgruppenwerte bleiben im Gesamtwert unberücksichtigt. Die Interpretation gilt für diese Audience, auch wenn einzelne Minds weiteren Audiences angehören.

Beispiel-Prompt:

"Validiere meine Zielgruppe 'German SaaS buyers' anhand veröffentlichter Umfragen und sag mir, wie nah sie dran ist."

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.

Ein Forschungslauf kann die Erhebung mit status: "partial" beenden, wenn eine Frage oder die Antwort eines Minds fehlt. Beende das Polling bei diesem Endzustand und erkläre die Lücke; bezeichne das Ergebnis nicht als vollständig. progress.pct misst abgeschlossene Fragen, nicht die Antwortabdeckung. Neue Fragenergebnisse speichern outputData.responseCoverage mit expected, received und den fehlenden Audience/Mind-Zuordnungen. progress.partial zählt Fragen mit dokumentierter unvollständiger Abdeckung. Fehlende Abdeckungsdaten bei älteren Ergebnissen belegen keine Vollständigkeit. Behalte gültige Rohantworten und deren Ergebnisse unverändert; prüfe fehlende Antworten vor einem separaten Wiederholungsversuch.

Auf Bereitschaft warten und fortfahren

Bitte Minds in ChatGPT Work im Web oder Work mit Cloud in der Desktop-App um eine Nachricht, sobald eine Zielgruppe bereit oder ein bestätigter Studienlauf beendet ist. Auch eine bereits genehmigte Studie kann nach der Zielgruppenbereitschaft fortgesetzt werden. Prüfe und bestätige zuerst Zielgruppenentwurf und Studienplan: Der erste Auftrag bestätigt keinen ungesehenen Plan, und ein Ereignis erlaubt weder zusätzliche Fragen noch weitere Läufe oder Ausgaben. Der Host bestimmt den Benachrichtigungskanal; eine SMS ist nicht garantiert.

Das Zielgruppenereignis wartet, bis die erstellten Minds nutzbar sind; eine Vorschau zur Prüfung ist nicht bereit. Das Studienereignis wartet auf die gespeicherte Ergebnissynthese. Unvollständige Antworten, vorläufige Zusammenfassungen, Fehler, Abbruch und Tariflimits werden mit ready=false gemeldet. Lies den ursprünglichen Lauf mit get_study_status({ study: { id: studyId }, runId }) und behalte seine Kennungen; starte ihn nicht allein wegen eines Ereignisses erneut.

Abonnements gelten höchstens 24 Stunden und müssen vor refreshBefore erneuert werden. Signierschlüssel und Callback-URLs werden verschlüsselt gespeichert. Die Zustellung prüft Verbindung, Kontoregeln und Ressourcenzugriff erneut. Ausstehende Zustände werden minütlich geprüft; Callback-Verifizierung und Wiederholungen können verzögern. Historische Ereignisse werden nicht nachgeliefert. Behalte bei fehlgeschlagener Anmeldung den Arbeitsbereich-Link und lies den Status; versprich erst nach erfolgreicher Anmeldung eine Nachricht.

Benenne die Überwachungsaufgabe nach der Forschung und dem gewünschten Meilenstein, ohne vorab einen Erfolg zu versprechen. Benachrichtigungen sollen in der Sprache des Nutzers mit dem Ergebnis und dem Forschungsnamen beginnen, direkt gefolgt vom Workspace-Link und dem nächsten Schritt. Dieser Anfang muss für sich verständlich sein: ChatGPT kann die vollständige Nachricht in der E-Mail-Vorschau kürzen. Ergänze eine kurze Erkenntnis sowie die Anzahl der Befragten oder Fragen nur, wenn gespeicherte Ergebnisse sie belegen. Ereignisnamen, interne Kennungen und JSON-Felder gehören nur auf ausdrücklichen Wunsch in gewöhnliche Abschlussmeldungen.

Bei einem Entwurf, der noch bestätigt werden muss, heißt es „bereit zur Prüfung“ und die Forschung hat noch nicht begonnen; die genaue Entwurfs-ID, Revision und Bestätigungsfragen bleiben im vollständigen Prüfgespräch. Lies bei fehlgeschlagener oder unvollständiger Arbeit get_audience_creation_progress({ operationId }) oder get_study_status({ study: { id: studyId }, runId }) für den ursprünglichen Vorgang. Erkläre die gemeldete Ursache, den gespeicherten Fortschritt, fehlende Teile und den möglichen nächsten Schritt; ist keine Ursache verfügbar, sage das. Erfinde keinen Grund und wiederhole die Forschung nicht automatisch. Melde nur gewünschte Meilensteine; bereits autorisierte Zwischenschritte laufen ohne weitere Nachricht, außer eine Prüfung ist nötig oder die Arbeit ist blockiert. Der Host kontrolliert E-Mail-Vorlage und Kanäle; eine direkte Schaltfläche in der E-Mail oder SMS lässt sich daher nicht versprechen.

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