Skip to main content
Glama

Minds: Synthetic Market Research Panels

Export Study Results

export_study
Idempotent

Starts an asynchronous export of Study results and returns an export job ID. Supports executive briefs and full reports in PDF, DOCX, PPTX, or Markdown, plus raw data in CSV, XLS, or SPSS SAV.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoReport kind. Defaults to full_report, except CSV/XLS/SAV which default to raw_data.
forceNoRegenerate instead of returning a cached artifact.
formatNoExport format: "pdf" (default), "docx", "pptx", "csv", "xls", "sav", or "md" (also accepts "markdown"). Executive-summary and full-report PPTX exports use a slide-native 16:9 layout.
lengthNoRequested report detail for executive_brief and full_report exports.
panelIdNoStudy ID (UUID; legacy wire field name: panelId). Omit both panelId and panelName only when exporting the active Study from this MCP session.
studyIdNoStudy ID (UUID). Omit with studyName to export the active Study.
panelNameNoStudy name (fuzzy matched; legacy wire field name: panelName). Omit both panelName and panelId only when exporting the active Study from this MCP session.
studyNameNoStudy name (fuzzy matched). Omit with studyId to export the active Study.
scheduledRunIdNoExport only the messages produced by one scheduled run of this Study, instead of the whole timeline. Use the run ID from the Study schedule history.

Schema Changelog

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

  1. Changed2 schema fields changed
    • changedInput schema / properties / format / description
      Previous value: -"Export format: \"pdf\" (default), \"html\" or \"png\" for executive summaries, \"docx\", \"pptx\", \"csv\", \"xls\", \"sav\", or \"md\" (also accepts \"markdown\"). Executive-summary PPTX exports use a slide-native 16:9 layout."New value: +"Export format: \"pdf\" (default), \"docx\", \"pptx\", \"csv\", \"xls\", \"sav\", or \"md\" (also accepts \"markdown\"). Executive-summary and full-report PPTX exports use a slide-native 16:9 layout."
    • changedInput schema / properties / format / enum
      Previous value: -[
      -  "pdf",
      -  "html",
      -  "png",
      -  "docx",
      -  "pptx",
      -  "csv",
      -  "xls",
      -  "sav",
      -  "md",
      -  "markdown"
      -]New value: +[
      +  "pdf",
      +  "docx",
      +  "pptx",
      +  "csv",
      +  "xls",
      +  "sav",
      +  "md",
      +  "markdown"
      +]
  2. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish idempotence and non-destructiveness, so the description's added value is its clarification that exports are asynchronous and yield a job ID. This is behavior beyond the structured annotations and helps an agent know not to expect the artifact in the immediate response. Some context, such as how to retrieve completion status, is left implicit but is not critical for the call itself.

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 two focused, front-loaded sentences: it immediately conveys the asynchronous behavior and return value before listing supported outputs. No filler or redundant explanation.

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 tool with 9 parameters but comprehensive schema descriptions, the description gives enough high-level orientation around purpose, formats, and the job-ID return. It lacks only minor operational detail such as how to poll the eventual export status, but the return contract is explicit and the remaining complexity is handled by the schema.

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?

The input schema has 100% parameter description coverage, so the schema already explains every parameter thoroughly. The description's format summary is helpful orientation but doesn't add significant semantic meaning beyond the schema. The 3 baseline is appropriate because the schema carries the semantic load.

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 names a specific action and resource ('starts an asynchronous export of Study results') and clearly separates this from sibling exporters like export_audience, export_heatmap, and export_mind by scoping it to Study results. It also states what the caller receives: an export job ID.

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 to call it: when exporting Study results asynchronously, in one of several listed formats. It does not explicitly name sibling tools or say when not to use them, but the resource scope and format list are enough to route an agent correctly in most cases.

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.