Skip to main content
Glama

Minds: Synthetic Market Research Panels

Create a Grounded Audience from a Brief

create_audience_from_brief
Idempotent

Creates a grounded Audience of synthetic Minds from a population or audience brief. It can combine authoritative web research, supplied sources, research files, and reviewed spreadsheet distributions; persists provenance and allocation audits; supports balanced, segment-coverage, and benchmark-depth sizing; can individually train every member of a large reviewed-dataset cohort in the background (trainMembers); is idempotent for identical inputs; and keeps the Audience private unless link sharing is enabled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional Audience name override. When omitted, the server names the Audience from the brief or the LLM detection result.
textNoLegacy alias for `brief`. Accepted for back-compat.
briefNoFree-text brief describing the population the Audience should represent. E.g. "California high school students grades 9-12", "Berlin Späti customers", "Spanish lawyers", "management team of Coca Cola". The server runs deep web research on this brief to find demographic / psychographic distributions from authoritative sources, then generates personas that proportionally reflect those distributions.
filesNoOptional already-uploaded research files. 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. The server analyzes these through the same extended screener/questionnaire path as the in-app New Audience uploader, including study roles, screening and quota rules, review distributions, and grounding provenance.
linksNoOptional URLs scraped server-side for additional context (e.g. an article describing the population).
keywordsNoOptional Exa web-search seeds added alongside the brief.
memberCountNoExact number of Minds to create in the Audience. Pass this whenever the user states a size ("exactly 50 per region", "genau 50 Minds je Zelle") instead of relying on the server to parse the number out of the brief prose. When omitted, the size is inferred from the brief and, failing that, from the creation mode's evidence-based automatic sizing. Rejected with 403 PLAN_LIMIT when it exceeds the plan's per-Audience cap; the Audience is never created at a partial size.
trainMembersNoOpt-in per-Mind training for large reviewed-dataset cohorts (default false). By default a reviewed-dataset Audience of more than ~40 Minds is bulk-created immediately ready: exact demographics, but no per-Mind research training (empty system prompt, no knowledge items). Set true to create those Minds untrained instead and enqueue each one through the same per-member training pipeline the in-app draft flow uses, preserving its deterministic cohort profile and the request locale. The tool still returns as soon as the Audience exists — training continues in the background (structuredContent.audience.memberTraining reports what was queued); poll each member with GET /api/v1/minds/{id}/training. Has no effect on Audiences whose members are already trained individually.
cohortAllocationNoDeterministic allocation controls. Reviewed respondent datasets default to observed, which preserves the strongest privacy-safe structural relationships while keeping exact marginals; other sources default to independence. Use distributionNames/maxDistributions to choose axes, minSegmentCount for a feasible floor, and seed for reproducible external runs.
includeWebSearchNoSet false to skip Exa web search and extraction completely. The Audience is then grounded only on the brief and supplied files, links, keywords, and structurally parsed respondent data.
groupCreationModeNoAudience creation mode. "balanced" (default): compact, representative Audience for everyday research. "segment_coverage": two representatives per limiting grounded audience cell, with a 10-Mind evidence floor and 50-Mind mode ceiling. "benchmark_depth": repeated representation of limiting grounded audience cells for validation-ready benchmark / survey-style segmentation, with the paid allowance as its ceiling. The deeper modes require a Team (enterprise) plan — on other plans the server SILENTLY downgrades to "balanced" and echoes the effective mode in the response (structuredContent.audience.audienceCreationMode). This field is the legacy alias for audienceCreationMode.
datasetSegmentationNoReviewed variable roles, distributions, and privacy-safe pairwise relationships returned by preview_audience_dataset_segmentation. Requires audienceCreationMode="benchmark_depth". Structural variables shape one generalizable representative cohort; outcomes remain held out and joint combinations remain audit evidence only. Copy `respondentCount` and `recommendedMindCount` through from the preview — they cap the cohort size.
audienceCreationModeNoAudience creation mode. Preferred. Use balanced for everyday research, segment_coverage for coverage of limiting grounded cells, or benchmark_depth for validation-ready repeated representation.
isLinkSharingEnabledNoSet true ONLY when the user explicitly asked for a public/shareable link. Defaults to false: the Audience is private to its owner and no share URL is generated. Enabling this publishes the Audience — including its grounding, sources and personas — at a world-readable URL that needs no login. Do not enable it to "be helpful".

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses substantial behavioral traits: idempotence for identical inputs, default privacy unless link sharing is enabled, silent downgrade to balanced mode on non-Team plans, rejection of partial-size creation, background training behavior, and provenance/allocation auditing. This goes well beyond what readOnlyHint, openWorldHint, idempotentHint, and destructiveHint already declare.

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 description is dense but earns its length given the tool's 14 parameters, nested objects, and capability breadth. It front-loads the core purpose, then lists behavioral guarantees and options. However, the long semicolon-heavy single-sentence structure reduces scannability; breaking it into short clauses or bullets would have earned a 5.

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 complex creation tool with no output schema, the description covers the essential operational context: what inputs are combined, sizing modes, idempotence, privacy, background training, and plan-dependent behavior. It does not describe the output shape, but the schema's parameter descriptions already reference key response fields (e.g., structuredContent.audience.memberTraining, effective audienceCreationMode), so an agent has enough to invoke it correctly.

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. The description adds value by synthesizing how parameter groups relate: combining web research, supplied files, links, keywords, and reviewed spreadsheet distributions; mapping sizing modes to balanced/segment-coverage/benchmark-depth; and explaining that training is an opt-in background behavior. It does not enumerate individual parameters, but the schema already does that thoroughly.

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 specific verb and resource: "Creates a grounded Audience of synthetic Minds from a population or audience brief." It names the input source, key capabilities, and clearly distinguishes this creation tool from sibling tools like ask_audience, export_audience, and create_study.

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 when to use the tool: whenever an agent needs to create a grounded synthetic Audience from a brief. It also supplies important conditional guidance inside parameter descriptions (e.g., set isLinkSharingEnabled only when explicitly asked, pass memberCount when the user states an exact size, use benchmark_depth for validation-ready cohorts). It does not explicitly name sibling alternatives or state when not to use it, so it stops 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation3/5

The tool set has three distinct get_panel_* tools and two draft-saving tools (plan_panel_study, save_study_draft) that could be confused, but the detailed descriptions clarify their specific scopes. Most other tools (list, create, export, ask) target clearly different resources or actions.

Naming Consistency5/5

All tool names follow a consistent verb_noun scheme in snake_case (list_, get_, create_, ask_, export_, plan_, run_, save_). Verb choice maps predictably to the operation, making the set easy to navigate.

Tool Count4/5

At 18 tools, the set is slightly above the ideal 3-15 range but well-scoped for a comprehensive research-panel platform. Each tool addresses a distinct part of the workflow, from group/panel creation to study planning, execution, and export.

Completeness4/5

The surface covers the full research lifecycle: create groups/panels, ask questions, monitor status, export artifacts, and plan/run multi-question studies. It lacks update/delete operations for groups and panels, but these are minor gaps that agents can work around for typical research flows.