LimeSurvey MCP Server

Import question group

limesurvey_import_group

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

Instructions

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

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

Input Schema

Name	Required	Description	Default
`survey_id`	Yes	Numeric LimeSurvey survey ID.
`import_data`	No	Base64-encoded group file contents; omit when using import_data_path.
`new_group_name`	No	Optional replacement group name.
`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 group 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 lsg.
`new_group_description`	No	Optional replacement group description.

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

B3/5.0

Behavior3/5

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=true, so the safety profile is provided. The description adds genuine value beyond annotations: it names the underlying RemoteControl method and states the auth model (configured service account, no session key). It does not disclose the side effect of creating a new group inside the survey or the non-idempotency implications.

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 short, front-loaded sentences with no filler. The file-size tip is actionable and the auth note prevents an obvious mistake (passing a session key).

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 a 7-param schema at full coverage, an output schema present, and annotations covering the safety profile, the description does enough: it states purpose, the file-vs-inline routing, and the auth mode. The main missing element is differentiation from sibling group/import tools.

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 every parameter including the import_data_path size/directory rule. The description's file-size guidance largely repeats the schema's own wording on import_data_path, adding little beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Import a question group into a survey'), but does not distinguish itself from the many siblings that could touch groups or question imports (e.g. add_group, add_group_from_spec, import_question). No note that import_group operates on an external file whereas add_group creates inline, so an agent could easily pick the wrong tool.

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

Usage Guidelines2/5

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

The description offers one routing hint (use import_data_path for files ≥ ~50 KB), which is really a parameter mechanic rather than a when-to-use-this-tool rule. It does not contrast with add_group or import_question, nor say when not to use it.

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

Deploy Server