Minds: Synthetic Market Research

Run a Confirmed Multi-Question Block

run_study_questions

Idempotent

Executes one stored draft revision inside its Study, after the person has explicitly confirmed that exact revision. One execution submits the whole draft — every named module and every question — as a single durable run; there is no per-question or per-module execution.

Before queuing, the server revalidates the revision, method availability and reviewed capabilities, and checks that required respondent-visible material is readable. It refuses the entire run if it is not, before any Mind is used or any quota spent.

Items are answered in order, as one respondent would: every Mind answers an item in parallel, and each Mind sees its own earlier answers in this run, never another Mind's. So an item may build on an earlier one, and order effects can arise as in a fielded survey. Items with askIf are asked only of Minds whose own earlier answer matched. After the run, answers that contradict the same Mind's other answers are flagged for review, never changed.

Input Schema

TableJSON Schema

Name	Required	Description
`draft`	Yes	The exact confirmed draft revision to execute.
`study`	No	Which Study to run in. Omit entirely to use the active Study from this MCP session.
`confirmed`	Yes	Must be true only after the user explicitly confirms this exact draft revision.
`audienceIds`	No	Optional subset of the Study's Audiences to include.
`idempotencyKey`	No	Stable UUID for safe retries.
`modelConnection`	No	Verified caller-team connection for Mind answers and verbatim rendering. Select only when the user requests it; confirmation pins this connection revision, and retries must keep it. Supporting analysis retains platform models.
`advancedMethodOptIn`	No	Explicit opt-in for an advanced method. Omit or false to keep simple methods.

Output Schema

TableJSON Schema

Name	Required	Description
`runId`	No	Durable run; poll it with get_study_run.
`status`	No	Run status, or stimulus_unavailable / plan_limited when nothing started.
`studyId`	No	Study the block runs in.
`workspaceUrl`	No	Minds workspace link for the Study.
`executionStarted`	No	False when nothing started.

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedSep 22, 2026

addedInput schema / properties / draft

Added value: +{
+  "description": "The exact confirmed draft revision to execute.",
+  "properties": {
+    "id": {
+      "description": "Exact draft plan ID returned by plan_study_questions.",
+      "format": "uuid",
+      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+      "type": "string"
+    },
+    "revision": {
+      "description": "Exact draft revision the user reviewed.",
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "id",
+    "revision"
+  ],
+  "type": "object"
+}

removedInput schema / properties / draftPlanId

Removed value: -{
-  "description": "Exact draft plan ID returned by plan_study_questions.",
-  "format": "uuid",
-  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
-  "type": "string"
-}

removedInput schema / properties / groupIds

Removed value: -{
-  "description": "Legacy alias for audienceIds. Accepted for compatibility.",
-  "items": {
-    "format": "uuid",
-    "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
-    "type": "string"
-  },
-  "type": "array"
-}

removedInput schema / properties / panelId

Removed value: -{
-  "description": "Study ID (UUID; legacy wire field name: panelId). Omit both panelId and panelName only to run the confirmed draft in the active Study from this MCP session.",
-  "format": "uuid",
-  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
-  "type": "string"
-}

removedInput schema / properties / panelName

Removed value: -{
-  "description": "Study name for fuzzy matching (legacy wire field name: panelName). Omit both panelName and panelId only to run the confirmed draft in the active Study from this MCP session.",
-  "type": "string"
-}

removedInput schema / properties / revision

Removed value: -{
-  "description": "Exact draft revision the user reviewed.",
-  "exclusiveMinimum": 0,
-  "maximum": 9007199254740991,
-  "type": "integer"
-}

addedInput schema / properties / study

Added value: +{
+  "description": "Which Study to run in. Omit entirely to use the active Study from this MCP session.",
+  "properties": {
+    "id": {
+      "description": "Study ID (UUID). Omit with studyName to run in the active Study.",
+      "format": "uuid",
+      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+      "type": "string"
+    },
+    "name": {
+      "description": "Study name to fuzzy-match among the newest 1,000 visible Studies; use studyId for older records. Omit with studyId to run in the active Study.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

removedInput schema / properties / studyId

Removed value: -{
-  "description": "Study ID (UUID). Omit with studyName to run in the active Study.",
-  "format": "uuid",
-  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
-  "type": "string"
-}

removedInput schema / properties / studyName

Removed value: -{
-  "description": "Study name to fuzzy-match among the newest 1,000 visible Studies; use studyId for older records. Omit with studyId to run in the active Study.",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "draftPlanId",
-  "revision",
-  "confirmed"
-]New value: +[
+  "confirmed",
+  "draft"
+]

Changed1 schema field changedSep 22, 2026

changedInput schema / properties / studyName / description

Previous value: -"Study name for fuzzy matching. Omit with studyId to run in the active Study."New value: +"Study name to fuzzy-match among the newest 1,000 visible Studies; use studyId for older records. Omit with studyId to run in the active Study."

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "executionStarted": {
+      "description": "False when nothing started."
+    },
+    "runId": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Durable run; poll it with get_study_run."
+    },
+    "status": {
+      "description": "Run status, or stimulus_unavailable / plan_limited when nothing started."
+    },
+    "studyId": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Study the block runs in."
+    },
+    "workspaceUrl": {
+      "anyOf": [
+        {
+          "type": "string"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Minds workspace link for the Study."
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 10, 2026

addedInput schema / properties / modelConnection

Added value: +{
+  "additionalProperties": false,
+  "description": "Verified caller-team connection for Mind answers and verbatim rendering. Select only when the user requests it; confirmation pins this connection revision, and retries must keep it. Supporting analysis retains platform models.",
+  "properties": {
+    "id": {
+      "format": "uuid",
+      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+      "type": "string"
+    },
+    "revision": {
+      "exclusiveMinimum": 0,
+      "maximum": 9007199254740991,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "id",
+    "revision"
+  ],
+  "type": "object"
+}

AddedAug 27, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations limited to readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, the description carries substantial extra behavioral weight: pre-queue revalidation with whole-run refusal before 'any Mind is used or any quota spent,' parallel answering with strict per-Mind answer isolation, askIf conditional asking, order-effect disclosure, and post-run contradiction flagging that is 'never changed.' This is rich, decision-relevant execution semantics far beyond what the annotations convey, and nothing contradicts them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded: the opening sentence states purpose and scope, and each subsequent paragraph earns its place by covering validation gates, execution ordering, askIf behavior, and post-run flagging. For a 7-parameter tool with nested objects and an orchestration engine, the length is proportional; there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's high complexity and the existence of an output schema (so return values need not be explained), the description covers the essential runtime semantics comprehensively: atomicity, validation-before-cost, concurrency, askIf routing, and contradiction handling. The only notable gap is the post-queue lifecycle — the description never says how an agent observes the queued run's progress or outcome, though the sibling get_study_status and the output schema partially cover that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents each parameter thoroughly; the baseline of 3 applies. The description adds conceptual glue — tying draft+confirmed into a single all-or-nothing execution and explaining that audienceIds/modelConnection scoping happens within one durable run — but it introduces no new per-parameter syntax or format details beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: 'Executes one stored draft revision inside its Study, after the person has explicitly confirmed that exact revision.' It further scopes itself with 'every named module and every question — as a single durable run; there is no per-question or per-module execution,' which clearly distinguishes it from per-item tools and the sibling run_study_heatmap. An agent can tell exactly what this tool does and what it is not.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description establishes a hard usage gate ('after the person has explicitly confirmed that exact revision') reinforced by the confirmed parameter, and the schema-level parameter docs add situational guidance ('Select only when the user requests it' for modelConnection; 'Omit entirely to use the active Study'). However, it never explicitly names alternatives or exclusion conditions versus siblings like ask_study or plan_study_questions, so it falls just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Minds: Synthetic Market Research tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.