Zelinqa MCP

What Zelinqa MCP MCP server does

Zelinqa MCP MCP server gives an MCP-compatible host a tool-driven way to run conversations defined in Zelinqa Studio. The domain determines what the conversation needs to learn and which question should come next. The assistant presents the returned question in its own words, while the server keeps the conversation identifiers and state.

The server is intended for flows where an assistant must ask questions before making a decision. Possible applications described by the project include interviews, qualification, orientation, triage, and recommendations. Results can include the current question, answer choices, progress by objective dimension, counters, warnings, and a reason for stopping.

How it works

A typical interaction begins with zelinqa_start, using a caller-provided conversation name. The server returns the first or currently pending question. The host then sends a person’s response to zelinqa_next_question, using free text or selected choice labels. The same tool returns the next question or indicates that the objective is complete.

Calling zelinqa_next_question without a response displays the pending question again without advancing the conversation. Existing information can be added without asking another question through zelinqa_add_context or zelinqa_adjust. zelinqa_status refreshes the current progress and pending question. When the conversation ends, zelinqa_feedback records whether the observed business result was a success, partial result, or failure.

Question selection is performed by the Zelinqa engine rather than generated by the language model. The project describes the selection as deterministic for the same state, with progress and stop information included in decision results. At the configured maximum turn count, the result stops with the max_turns_reached reason.

Setup and configuration

The Zelinqa MCP MCP server requires Python 3.11 or newer, uv, and a runtime API key for a published domain. The key is created in Zelinqa Studio; the README says a Developer edition account is sufficient. Store the key in the host’s secret environment configuration rather than embedding it in conversation data.

The standard stdio command is:

uvx zelinqa-mcp

Set the required environment variable before starting the process:

ZELINQA_API_KEY=YOUR_RUNTIME_API_KEY

The README provides setup examples for Claude Desktop, Cursor, Windsurf, Claude Code, VS Code, and Codex. A source checkout can be prepared with uv sync --group dev --locked, followed by uv run zelinqa-mcp --version.

Tools and capabilities

The available tools are:

• zelinqa_start: Start or recover a named conversation and return its first or pending question.
• zelinqa_next_question: Submit a reply and obtain the next question, or redisplay the pending question without a reply.
• zelinqa_add_context: Add a context summary without asking a question.
• zelinqa_adjust: Apply confirmed data, dimension statuses, or an objective override without using a turn.
• zelinqa_status: Refresh progress and the pending question.
• zelinqa_feedback: Record a success, partial, or failure outcome.
• zelinqa_forget: Release the local handle without deleting data held by the API.

The model receives question text, choice labels, and conversation naming information. Session, decision, and state identifiers remain inside the server. This design is relevant when the host should handle dialogue presentation while Zelinqa controls question selection and state progression.