Skip to main content
Glama

Minds: Synthetic Market Research Panels

Ask One Standalone Question in a Study

ask_study
Idempotent

Submits exactly ONE respondent-visible question in an existing Study. Applicability: one standalone question, or one adaptive follow-up whose wording could not be known before earlier results. Exclusion: never use this operation for a questionnaire, survey, battery, section, cohesive question set, or any request containing two or more known questions—even when every question targets the same Study. The complete known set belongs in one planned and confirmed multi-question block inside the Study and must be submitted once, not question by question. Follow-up questions remain within the existing Study; this operation does not create or enumerate Studies. The full question value may reach respondents and is not planner-only metadata. Scale, categorical, and qualitative questions are classified automatically, and the response includes status and workspace links. Automatic classification may reformulate the question; this operation does not promise verbatim wording. Locked respondent wording and response formats require a reviewed and confirmed Study plan. The question is classified before it is queued, so the returned status is authoritative: queued or running means it was submitted to respondents, while planning_required means it was declined as an unrefined research objective and nothing was submitted. A planning_required response carries the original request plus a proposed headline and respondent questions for study planning. MCP cannot read or upload a local file:// path. Use a fetchable HTTP(S) URL, a signed URL supplied by the client for the attached file, or an existing Minds workspace upload URL/path. Study tools import external file URLs into durable Minds storage before saving or running. The Study refuses to start if Minds cannot read the asset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
linksNoWeb pages given to every Mind as evidence for this question through v1 /studies/{studyId}/runs.
modelNoOptional per-request model override. Must be sent together with provider.
panelIdNoStudy ID (UUID; legacy wire field name: panelId). Omit both panelId and panelName only when continuing the active Study from this MCP session.
studyIdNoStudy ID (UUID). Omit with studyName to continue the active Study from this MCP session.
groupIdsNoLegacy alias for audienceIds. Accepted for compatibility.
keywordsNoSearch keywords used to gather evidence for this question through v1 /studies/{studyId}/runs.
providerNoProvider for the model override. Must be sent together with model.
questionYesExactly ONE respondent-visible standalone question or result-dependent adaptive follow-up for every selected Mind. Never concatenate, enumerate, or otherwise place a questionnaire, survey, battery, section, cohesive question set, or two or more known questions in this field. The system may classify or reformat it, but any text here can reach the Minds and influence their answers. Include only the single question, its necessary stimulus, and respondent-facing instructions. Never place planner-only or MCP-client orchestration instructions here.
panelNameNoStudy name (fuzzy matched; legacy wire field name: panelName). Omit both panelName and panelId only when continuing the active Study from this MCP session.
studyNameNoStudy name (fuzzy matched). Omit with studyId to continue the active Study from this MCP session.
attachmentsNoFiles/images processed once and given to every participating Mind. MCP cannot read or upload a local file:// path. Use a fetchable HTTP(S) URL, a signed URL supplied by the client for the attached file, or an existing Minds workspace upload URL/path. Study tools import external file URLs into durable Minds storage before saving or running. The Study refuses to start if Minds cannot read the asset.
audienceIdsNoOptional subset of the Study's Audiences to ask; defaults to all Audiences.
historyModeNoControls prior Study-history carryover for this one direct question. Defaults to none, so this measurement is independent of earlier Study questions. last5 is only for a conversational/adaptive question that requires respondent continuity; it costs roughly 2.4x wall-clock for about 0.6pp of accuracy. followup_only carries history only when the submitted question is classified as a conversational follow-up.
sourcePolicyNoUse knowledge_only to forbid web/request sources and require every answer to be grounded in processed Mind knowledge.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / properties / attachments / items / properties / id
      Added value: +{
      +  "description": "Stable asset ID used by questionAttachments to assign this file to specific planned questions.",
      +  "maxLength": 255,
      +  "minLength": 1,
      +  "type": "string"
      +}
  2. Changed3 schema fields changed
    • changedInput schema / properties / attachments / description
      Previous value: -"Files/images processed once and given to every participating Mind. MCP cannot read or upload a local file:// path. Use a fetchable HTTP(S) URL, a signed URL supplied by the client for the attached file, or an existing Minds workspace upload URL/path. The Study refuses to start if Minds cannot read the asset."New value: +"Files/images processed once and given to every participating Mind. MCP cannot read or upload a local file:// path. Use a fetchable HTTP(S) URL, a signed URL supplied by the client for the attached file, or an existing Minds workspace upload URL/path. Study tools import external file URLs into durable Minds storage before saving or running. The Study refuses to start if Minds cannot read the asset."
    • changedInput schema / properties / attachments / items / properties / path / description
      Previous value: -"Storage path of a file already uploaded to Minds. MCP cannot read or upload a local file:// path. Use a fetchable HTTP(S) URL, a signed URL supplied by the client for the attached file, or an existing Minds workspace upload URL/path. The Study refuses to start if Minds cannot read the asset."New value: +"Storage path of a file already uploaded to Minds. MCP cannot read or upload a local file:// path. Use a fetchable HTTP(S) URL, a signed URL supplied by the client for the attached file, or an existing Minds workspace upload URL/path. Study tools import external file URLs into durable Minds storage before saving or running. The Study refuses to start if Minds cannot read the asset."
    • changedInput schema / properties / attachments / items / properties / url / description
      Previous value: -"Fetchable HTTP(S), signed, or Minds workspace upload URL. MCP cannot read or upload a local file:// path. Use a fetchable HTTP(S) URL, a signed URL supplied by the client for the attached file, or an existing Minds workspace upload URL/path. The Study refuses to start if Minds cannot read the asset."New value: +"Fetchable HTTP(S), signed, or Minds workspace upload URL. MCP cannot read or upload a local file:// path. Use a fetchable HTTP(S) URL, a signed URL supplied by the client for the attached file, or an existing Minds workspace upload URL/path. Study tools import external file URLs into durable Minds storage before saving or running. The Study refuses to start if Minds cannot read the asset."
  3. Added

TDQS

A4.6/5.0
Behavior5/5

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

Despite useful annotations (idempotentHint, openWorldHint, destructiveHint=false), the description carries substantial extra behavioral weight: automatic classification may reformulate the question so verbatim wording is not promised, the returned status is authoritative (queued/running means actually submitted, planning_required means declined with nothing submitted), and the planning_required payload is described. It also warns the full question value reaches respondents and that MCP cannot read local file:// paths. This far exceeds what the annotations convey.

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

Conciseness3/5

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

The core purpose is front-loaded and essentially every sentence carries decision-relevant content, but the description is verbose. The file:// limitation is stated in the description and then repeated three more times across schema attachment properties, and the 'never use for multi-question' exclusion is restated multiple times. It is substantive, not bloated, but could be tightened by roughly a third without losing information.

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?

For a 14-parameter tool with no output schema, the description compensates well: it defines the three possible status outcomes and what planning_required returns, explains classification/reformulation risk, and clarifies file URL constraints and durable storage import. Minor gaps remain—the response shape is only partially described ('status and workspace links'), and active-session continuation semantics live only in the schema—but nothing critical is missing for correct invocation.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3 with the schema doing the heavy lifting. The description adds value beyond the schema for the question parameter by explaining the system may classify or reformat it and that any text can reach Minds, and it reinforces attachment URL constraints. This lifts it above baseline, though the description does not systematically walk through each parameter.

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 description opens with a precise verb+resource+scope: 'Submits exactly ONE respondent-visible question in an existing Study.' This is immediately distinguishable from siblings like plan_study_questions, run_study_questions, and create_study because it scopes to a single question inside an existing Study and explicitly says it does not create or enumerate Studies.

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

Usage Guidelines5/5

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

The description provides explicit applicability ('one standalone question, or one adaptive follow-up whose wording could not be known before earlier results') and an explicit exclusion: never for questionnaires, surveys, batteries, sections, cohesive question sets, or two or more known questions. It also names the correct alternative routing—the complete known set belongs in 'one planned and confirmed multi-question block'—so an agent knows exactly when to choose a different tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, from audience creation and study management to question planning/execution and exports. Even the similar ask_audience and ask_study are unambiguously differentiated by scope (audience-level vs study-level), and the extensive descriptions reinforce the boundaries.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., list_audiences, create_study, export_study). There are no mixed conventions or vague verbs, making the naming highly predictable.

Tool Count4/5

With 19 tools, the count is at the upper end of reasonable for a complex domain like market research panels, but each tool serves a distinct function. The set is not bloated; it reflects the multifaceted nature of managing audiences, studies, questions, and exports.

Completeness3/5

The surface covers the core research lifecycle—create audience/study, plan and run questions, monitor status, and export results. However, it lacks update and delete operations for audiences and studies, which are typical CRUD gaps that agents may encounter. The workflow is otherwise complete.