Skip to main content
Glama

Minds: Synthetic Market Research Panels

by ai.getminds

Create a Study

create_study
Idempotent

Creates a new Study workspace from existing Audiences or inline Audience configurations; it does not ask questions or run research. Follow-up research in an existing Study does not require another Study. Every questionnaire, survey, battery, section, cohesive question set, or request with two or more known questions belongs in one planned and confirmed multi-question block inside that Study. Never submit such a known set as separate direct questions. A direct question is appropriate only when exactly one standalone question is known or the next question depends on earlier results. Composite creation is atomic and rolls back partial Audience failures. Studies are private by default; enabling link sharing also publishes the attached Audiences and Minds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesName for the Study workspace (e.g., "Brand Perception Study", "Q4 Market Research")
groupIdsNoLegacy alias for audienceIds.
audienceIdsNoPreferred field for existing Audience IDs to attach — use list_audiences to find IDs.
groupConfigsNoLegacy alias for audienceConfigs.
audienceConfigsNoPreferred field for new Audiences to create and attach atomically.
isLinkSharingEnabledNoSet true ONLY when the user explicitly asked for a public/shareable Study link. Defaults to false: the Study is private to its owner and no share URL is generated. Enabling this ALSO publishes every attached Audience and every Mind inside them at world-readable URLs — including pre-existing Audiences passed via audienceIds. Do not enable it to "be helpful".

Schema Changelog

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

  1. Changed1 schema field changed
    • removedInput schema / properties / groupConfigs / items / properties / sparkIds
      Removed value: -{
-  "description": "Legacy alias for mindIds.",
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}
  2. Changed5 schema fields changed
    • changedInput schema / properties / groupConfigs / description
      Previous value: -"Legacy alias for audienceConfigs. Accepted for compatibility."New value: +"Legacy alias for audienceConfigs."
    • removedInput schema / properties / groupConfigs / items / properties / mindIds / description
      Removed value: -"Mind IDs to add to this Audience — use list_minds to find IDs"
    • removedInput schema / properties / groupConfigs / items / properties / name / description
      Removed value: -"Audience name (optional — defaults to \"Audience N\"). E.g., \"Gen Z Consumers\", \"Marketing Experts\""
    • changedInput schema / properties / groupConfigs / items / properties / sparkIds / description
      Previous value: -"Legacy alias for mindIds. Accepted for back-compat."New value: +"Legacy alias for mindIds."
    • changedInput schema / properties / groupIds / description
      Previous value: -"Legacy alias for audienceIds. Accepted for compatibility."New value: +"Legacy alias for audienceIds."
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

The description adds meaningful behavioral context beyond the annotations: composite creation is atomic and rolls back partial Audience failures, Studies are private by default, and enabling link sharing publishes attached Audiences and Minds. These are non-obvious side effects an agent needs to know. No contradiction with the annotations.

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

Conciseness4/5

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

The core action is front-loaded, and every sentence contributes usage or behavioral guidance. The enumeration 'questionnaire, survey, battery, section, cohesive question set, or request with two or more known questions' is somewhat verbose but not padding.

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?

Combined with the rich schema and annotations, the description gives an agent enough to use the tool correctly: creation sources, multi-question workflow rules, atomicity, and privacy side effects. The only modest gap is that no output or return value is described, though no output schema exists.

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%, and the schema already documents each parameter, preferred vs legacy aliases, defaults, and the sharing side effect in detail. The description only reinforces the conceptual split between existing Audiences and inline configurations without adding new parameter-level semantics, so the baseline score of 3 is appropriate.

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 states a specific action and resource: 'Creates a new Study workspace from existing Audiences or inline Audience configurations.' It also explicitly distinguishes itself by noting it 'does not ask questions or run research,' which separates it from sibling tools like ask_study and ask_audience.

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 clear when-to-use and when-not-to-use guidance: follow-up research does not require another Study, multi-question sets must not be submitted as separate direct questions, and a direct question is appropriate only for a standalone or dependent next question. This is actionable routing guidance beyond simple context.

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 Panels toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources