LimeSurvey MCP Server

Validate a survey description

limesurvey_validate_spec

Read-onlyIdempotent

Check a survey description (spec) and report every problem at once. kind says what the spec is: survey ({ survey, groups }), group (one group with its questions) or question (one question).

Instructions

Check a survey description (spec) and report every problem at once. kind says what the spec is: survey ({ survey, groups }), group (one group with its questions) or question (one question). Returns { valid, kind, errors [{ path, message, fix }], errors_total, warnings [{ path, message }], warnings_total, truncated, summary, checked_against_survey, skipped_checks }. errors and warnings show at most 200 entries and are cut further to stay within LIMESURVEY_MAX_RESPONSE_CHARS; errors_total and warnings_total hold the full numbers and truncated says whether a list was cut. Paths are 0-based, for example groups[1].questions[3].answers[0].code; for kind group and question they are relative to the checked object (for example code). The check covers keys, question codes (pattern, length, reserved words, duplicates), question types and the subquestions and answers each type needs, answer and subquestion codes, attribute names, attributes that some question theme defines but the theme of the question does not (plugin attributes and unknown themes are not checked), a question_theme_name of another question type, language codes (each once, none equal to the base language), survey.format, survey.expires (a real date and time), XML-forbidden characters and embedded data URIs. A text is one string (for every language) or a map per language; the map must name exactly the languages of the survey (a default value may name fewer); an empty question, subquestion or answer text is a warning. An attribute takes a map when it is stored per language (prefix, suffix, ...) or when no question theme lists it (a plugin attribute), not when it is known to be language independent. default is refused on questions with subquestions and on types R and |. An entry of a Ranking question may have a code of up to 20 characters and a relevance only on LimeSurvey 7: without survey_id this is a warning, with survey_id and kind group or question the version of the instance decides. Without survey_id nothing is sent to LimeSurvey and skipped_checks lists the checks that need the survey (for kind survey the languages come from the spec itself); with survey_id the tool reads the survey (read methods only) and also reports question codes that already exist in it and holds language maps to its languages. The types with a second scale are checked with their scale_id: type 1 needs subquestions (scale 0) and answers on scale 0 and 1, the types : and ; need subquestions on scale 0 (rows) and 1 (columns) and take no answers; codes are unique per scale; scale_id 1 elsewhere and default values on these three types are errors. The tool does not create or change anything; limesurvey_create_survey_from_spec creates a survey from a valid survey spec and limesurvey_get_survey_spec reads a survey, group or question as a spec.

Input Schema

Name	Required	Description	Default
`kind`	No	What the spec describes: survey (default), group or question.	survey
`spec`	Yes	The survey description. Its fields depend on kind; unknown fields are reported by the check, not rejected.
`survey_id`	No	Optional ID of an existing survey; for kind group and question its existing question codes are checked as well.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.0Oct 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: it never creates or changes anything, reads via read methods only when survey_id is given, truncates errors/warnings at 200 entries and further to LIMESURVEY_MAX_RESPONSE_CHARS with truncated/errors_total flags, and lists what skipped_checks reports. This is rich behavioral detail not derivable from annotations.

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?

It is front-loaded with the core purpose, and most sentences carry genuine validation rules, but the bulk is a single dense paragraph with no visual structure, making it hard to scan. For a tool this complex, more chunking would help, but nothing is obviously expendable filler.

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 the nested schema, output schema, and the intricate validation scope, the description covers the operating modes, truncation behavior, path conventions, and check coverage thoroughly. An agent has everything needed to call it correctly for any kind value.

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 description coverage is 100%, so the baseline is 3, but the description adds real semantic depth beyond the schema: the meaning of kind values, the map-vs-string language rules, default restrictions on subquestion/R/| types, and scale_id semantics (types 1, :, ; and their scale 0/1 requirements). It goes past restating field names.

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 and resource: 'Check a survey description (spec) and report every problem at once.' It explicitly distinguishes itself from siblings, naming limesurvey_create_survey_from_spec (which creates a survey from a valid spec) and limesurvey_get_survey_spec (which reads a spec), and clarifies it creates or changes nothing.

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?

Gives explicit when-to-use guidance and alternatives: use this to validate before creating, use create_survey_from_spec to create, use get_survey_spec to read. It also details the survey_id conditional behavior (with survey_id it reads the survey and checks existing codes; without it, nothing is sent and skipped_checks lists deferred checks), so the agent knows the two operating modes.

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

Deploy Server