LimeSurvey MCP Server

Export survey structure to a file (experimental)

limesurvey_export_survey_to_file

Attempt to export a survey's structure as .lss and write it inside LIMESURVEY_EXPORT_DIR, returning a path instead of base64.

Instructions

Attempt to export a survey's structure as .lss and write it inside LIMESURVEY_EXPORT_DIR, returning a path instead of base64. Core LimeSurvey 6 RemoteControl has neither export_survey nor export_survey_structure (verified against the LimeSurvey 6.17.11 source). The tool asks export_survey_structure(sessionKey, surveyId) first and export_survey(sessionKey, surveyId) second, so it only works if a plugin on the LimeSurvey side serves one of them; it requires LIMESURVEY_ENABLE_EXPERIMENTAL_METHODS=true and otherwise fails with EXPORT_UNSUPPORTED. Facts (checked 2026-10-11): no known 6.x plugin offers a structure export over RemoteControl (no verified plugin known); the RemoteControl handler class itself cannot be extended by a plugin, but a plugin can answer additional methods on the core URL (see LimeSurvey 6.17.11 source). Upstream, LimeSurvey pull request #5384 adds export_survey_structure for the 7.x line (open, not in any release); an own small plugin with that method works with this tool. Without an export, limesurvey_verify_survey_against_lss compares a .lss file with the live survey using read-only calls only.

Input Schema

Name	Required	Description	Default
`file_name`	No	Optional output file name without a directory.
`overwrite`	No	Allow replacing an existing file.
`survey_id`	Yes	Numeric LimeSurvey survey ID.
`document_type`	No	Structure export format.	lss
`confirm_overwrite`	No	Required acknowledgement when overwrite is true.

Output Schema

Name	Required	Description	Default
`result`	Yes
`workflow`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.3.1Jul 29, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds real context beyond them: it writes a file to disk rather than returning base64, the internal method fallback order, the exact error code on failure, and the plugin/upstream availability situation. It does not describe overwrite collision behavior beyond the schema's own flags, so a 4 is fair.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Purpose is correctly front-loaded, but the body is dense with internal sourcing detail (LimeSurvey 6.17.11, handler-class extensibility, PR #5384, a checked-on date) that goes beyond what an agent needs to select and call the tool. Much of it is informative for a human maintainer but inflates the definition for selection purposes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists and return values need not be explained, the description covers everything an agent needs: prerequisites, fallback mechanics, failure code, and the related verification tool. For an explicitly experimental capability, the incompleteness is disclosed rather than hidden.

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 file_name, overwrite, confirm_overwrite, document_type, and survey_id are already fully documented in the schema. The description adds only the implicit .lss format and the export-directory location; the baseline 3 applies when structured fields do the heavy lifting.

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 first sentence states a specific verb (export), resource (a survey's structure), format (.lss), destination (LIMESURVEY_EXPORT_DIR), and output shape (a path rather than base64). It is clearly distinguishable from the response-export siblings and from limesurvey_verify_survey_against_lss.

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?

It explicitly states the preconditions (LIMESURVEY_ENABLE_EXPERIMENTAL_METHODS=true, a plugin serving export_survey_structure/export_survey), the failure mode when unmet (EXPORT_UNSUPPORTED), and the alternative path (verify_survey_against_lss for read-only comparison). When-to-use, when-it-will-fail, and alternatives are all present.

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

Deploy Server