Skip to main content
Glama
yrvelez

Qualtrics MCP Server

by yrvelez

create_question

Create a survey question in a Qualtrics block with full control over payload, supporting all question types and advanced fields like validation, JavaScript, and custom configurations.

Instructions

Create a question in a survey block with full payload control. For Matrix questions: Choices = rows/statements, Answers = columns/scale points (both required). Use additionalFields to pass any other Qualtrics question-definition fields (e.g., a template from get_question_template). For common types, prefer the add_*_question helpers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
answersNoAnswer definitions keyed by answer number (columns/scale points — required for Matrix)
blockIdYesThe block ID to add the question to
choicesNoChoice definitions keyed by choice number (rows/statements for Matrix)
selectorYesQuestion selector (e.g., SAVR, MAVR, SL, ML, Likert, TB)
surveyIdYesThe Qualtrics survey ID
questionJSNoJavaScript to attach to this question (QuestionJS). IMPORTANT: Avoid literal `${` in JS strings — Qualtrics interprets it as piped text and corrupts the code. Use `\x24{` or `String.fromCharCode(36)+'{'` instead.
validationNoValidation settings
answerOrderNoDisplay order of answer keys (derived from answers if omitted)
choiceOrderNoDisplay order of choice keys (derived from choices if omitted)
subSelectorNoSub-selector if applicable (e.g., TX, SingleAnswer)
questionTextYesThe question text (HTML supported)
questionTypeYesQualtrics question type (e.g., MC, TE, Matrix, Slider, RO, CS, DB)
recodeValuesNoNumeric recode mapping keyed by choice/answer id
configurationNoConfiguration object (e.g., {QuestionDescriptionOption: 'UseText', TextPosition: 'inline'})
dataExportTagNoCustom export tag (recommended; a readable unique tag derived from questionText is generated if omitted)
additionalFieldsNoAny other question-definition fields, applied before the explicit fields above (e.g., SBS AdditionalQuestions, slider configs, a get_question_template result)
questionDescriptionNoInternal label shown in the editor (derived from questionText if omitted)
Behavior3/5

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

Annotations declare destructiveHint: false, so the description doesn't need to reiterate non-destructiveness. It adds context about Matrix requirements (choices/answers) but does not disclose the important warning about literal `${` in questionJS (only in schema). Behavioral transparency is adequate but not enhanced beyond 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, no redundancy, front-loaded with main purpose. Every sentence earns its place.

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?

Given the complexity (17 params, nested objects, no output schema), the description provides high-level context: full payload control, Matrix specifics, helpers, templates. It does not cover all parameter behaviors but is fairly complete for an overview.

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%, so baseline is 3. The description emphasizes the Matrix distinction, but the schema already explains choices and answers. No additional semantics beyond what schema provides.

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 clearly states the tool creates a question in a survey block with full payload control. It distinguishes from sibling helpers by saying 'For common types, prefer the add_*_question helpers.' The verb and resource are specific.

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?

Explicitly advises when to use this tool versus alternatives: 'For common types, prefer the add_*_question helpers.' Also suggests using additionalFields for templates, giving clear context.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yrvelez/qualtrics-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server