LimeSurvey MCP Server

Import question

limesurvey_import_question

Import a question into a survey group. Use import_data_path for files at or above roughly 50 KB instead of inline import_data.

Instructions

Import a question into a survey group. Use import_data_path for files at or above roughly 50 KB instead of inline import_data.

Calls LimeSurvey RemoteControl method import_question. Authentication uses the configured service account; do not provide a session key.

Input Schema

Name	Required	Description	Default
`group_id`	Yes	Numeric question-group ID.
`mandatory`	No	Whether the imported question is mandatory.
`survey_id`	Yes	Numeric LimeSurvey survey ID.
`import_data`	No	Base64-encoded question file contents; omit when using import_data_path.
`response_format`	No	Output format. JSON preserves the complete structured result; Markdown is optimized for reading.	json
`import_data_path`	No	Local file path to a question file. The server reads and base64-encodes it, so use this instead of inline import_data for files at or above roughly 50 KB. The file must live inside LIMESURVEY_IMPORT_DIR (or LIMESURVEY_EXPORT_DIR as a fallback). Exactly one of import_data or import_data_path must be set.
`import_data_type`	Yes	Import type supported by the LimeSurvey instance, normally lsq.
`new_question_help`	No	Optional replacement help text.
`new_question_text`	No	Optional replacement question text.
`new_question_title`	No	Optional replacement question code/title.

Output Schema

Name	Required	Description	Default
`method`	Yes
`result`	Yes
`warnings`	No
`truncated`	No
`truncation_message`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.6.0Oct 14, 2026

addedOutput schema / properties / warnings

Added value: +{
+  "items": {
+    "$ref": "#/definitions/__schema0"
+  },
+  "type": "array"
+}

First observedv1.3.1Jul 29, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true). The description adds useful context beyond them: it runs via the configured service account with no session key required, and discloses the file-size threshold behavior for path-based import. Minor gaps remain on failure/overwrite semantics, but it is a solid addition to annotation coverage.

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?

Three tight sentences, front-loaded with the core action and then the key routing caveat and auth note. Each sentence carries information, though the auth line is somewhat tangential to invocation mechanics.

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?

With an output schema present and rich annotations, the description needn't explain return values, and it correctly focuses on the operational gotchas (path vs inline, service-account auth). It is adequately complete for a 10-param import tool, though it could say more about how an imported question interacts with existing questions.

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 the schema already documents all ten parameters, including the import_data/import_data_path mutual-exclusion and the 50 KB threshold. The description largely restates the path-vs-inline guidance without adding syntax or format detail beyond the schema, so the baseline 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?

States a specific verb (import), resource (question), and target scope (into a survey group). This cleanly distinguishes it from siblings like import_group, import_survey, and replace_question without needing to open their schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides one concrete routing rule (use import_data_path for files ≥~50 KB instead of import_data) and an auth note. However, it never distinguishes this tool from plausible alternatives such as replace_question or add_question_from_spec, leaving the when-to-use-vs-alternatives question largely implied.

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

Deploy Server