LimeSurvey MCP Server

Get language properties

limesurvey_get_language_properties

Read-onlyIdempotent

Instructions

Read localized survey properties. The attachments field is returned exactly as LimeSurvey stores it (a JSON string since DB version 647, a PHP serialize string on older instances; keep it unchanged for a round trip to set_language_properties). When it is part of the answer, attachments_parsed is added: { : [ { file_name, url, size, relevance } ] } with the mail types invitation, reminder, registration, confirmation, admin_notification and admin_detailed_notification; an empty value gives {} and an unparsable one gives null plus a warning. LimeSurvey drops requested property names that are not a column of the survey language settings without saying so: such names are listed in the warning unknown_fields (if every name is unknown the call fails with the no-data hint). An unknown or missing language silently falls back to the base language. RemoteControl has no method that lists the uploaded survey files themselves; attachments only references them by server path.

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

Input Schema

Name	Required	Description	Default
`language`	No	LimeSurvey language code; null uses the survey default.
`survey_id`	Yes	Numeric LimeSurvey survey ID.
`properties`	No	Properties to return for the survey language; null returns all available properties.
`response_format`	No	Output format. JSON preserves the complete structured result; Markdown is optimized for reading.	json

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

A4.3/5.0

Behavior5/5

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

With annotations already covering read-only/idempotent/open-world, the description still adds substantial behavior: the attachments JSON-string vs PHP-serialize version split, the attachments_parsed shape and mail types, empty vs unparsable handling (with warning), the unknown_fields warning and no-data failure hint, and the silent language fallback. This is exactly the extra context annotations cannot express.

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?

It is dense but front-loaded with the core purpose, then proceeds to caveats. Every sentence carries non-redundant information, though a few clauses (e.g., the file-listing aside) are run-on and could be tightened.

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?

For a read tool with an output schema, the description need not restate return values, yet it still covers the tricky parts an agent would otherwise miss: version-dependent serialization, parsed-attachment structure, warning semantics, and language fallback. Nothing material is left for the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: what a null/unknown language resolves to (base language) and what happens to requested property names that are not real columns (silently dropped, surfaced in unknown_fields).

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

Purpose4/5

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

The description states a specific verb+resource: 'Read localized survey properties,' which cleanly separates it from limesurvey_get_survey_properties and the write-side limesurvey_set_language_properties. It does not explicitly name the sibling it differs from, but the scope is unambiguous.

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?

It gives clear contextual guidance: attachments must be kept unchanged for a round trip to set_language_properties, unknown/missing language falls back to the base language, and it notes RemoteControl offers no file-listing method. It stops short of explicit when-to-use-vs-alternative routing, so it is not a 5.

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

Deploy Server