Skip to main content
Glama

Minds: Synthetic Market Research Panels

by ai.getminds

Get Study Status

get_study_status
Read-onlyIdempotent

Returns the current Study state, live progress for in-flight questions, completed per-Audience results, linked Minds, Study links, and the status of a specific asynchronous export job when export identifiers are supplied. Values can be numeric answers or classified summary labels; message fields contain the original Mind responses when available. locale is the Study display locale, not a guarantee of the language of every response.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
panelIdNoStudy ID (UUID; legacy wire field name: panelId). Omit both panelId and panelName only for the active Study from this MCP session.
studyIdNoStudy ID (UUID). Omit with studyName to use the active Study.
panelNameNoStudy name (fuzzy matched; legacy wire field name: panelName). Omit both panelName and panelId only for the active Study from this MCP session.
studyNameNoStudy name (fuzzy matched). Omit with studyId to use the active Study.
exportKindNoAsynchronous export kind whose status should be returned (defaults to full_report).
exportJobIdNoExport job ID returned by export_study. Pass it with exportKind and exportFormat to poll that exact artifact.
exportFormatNoAsynchronous export format whose status should be returned (defaults to pdf). HTML and PNG are accepted here only to finish polling previously created executive-summary jobs.

Schema Changelog

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

  1. Changed1 schema field changed
    • changedInput schema / properties / exportFormat / description
      Previous value: -"Asynchronous export format whose status should be returned (defaults to pdf)."New value: +"Asynchronous export format whose status should be returned (defaults to pdf). HTML and PNG are accepted here only to finish polling previously created executive-summary jobs."
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds meaningful nuance: values may be numeric answers or classified labels, message fields contain original Mind responses when available, and locale is only the display locale, not a language guarantee. These go beyond 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.

Conciseness5/5

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

Three sentences with no filler: the first is front-loaded with the primary return resource and its major categories, the second clarifies value semantics, and the third adds an important locale caveat. Every sentence earns its place and no schema content is redundantly repeated.

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 read-only status tool with no output schema, the description inventories the main return categories and clarifies ambiguous fields (values, message, locale). It does not specify the exact export job states or response shape, but the annotations and detailed parameter schema make the description sufficient for selection and invocation.

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 coverage is 100% and each parameter is already documented in detail, including legacy field names, UUID formats, defaults, and omission rules for the active Study. The description adds only the general notion that export identifiers trigger job-status mode, which the schema already supports for the individual parameters. This meets the baseline but does not materially extend the schema.

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 ('Returns') and names the resource ('current Study state'), then enumerates distinct facets: live progress, completed per-Audience results, linked Minds, Study links, and export job status. This clearly distinguishes it from siblings like get_study_summary or get_study_run, and the export-polling mode is explicitly identified.

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 gives clear context for when the tool applies: querying overall study state, and specifically polling an asynchronous export when export identifiers are supplied. It does not explicitly name alternatives or state when not to use it, but the trigger condition for the export-job mode is stated clearly.

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