Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LiquidSoapMCP Create a Liquidsoap 2.4.0 script for an Icecast stream with crossfade"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
LLMs get Liquidsoap wrong a lot. Mixing 1.x docs, outdated blog posts, and half-remembered API examples.
This MCP server fixes that.
It gives your AI assistant (Claude, ChatGPT, Cursor, Windsurf, etc.) real Liquidsoap 2.4.0 documentation, examples, and API references, making it finally possible to:
Understand .liq scripts
Generate correct 2.4.0 code
Fix errors and deprecated usage
Explore operators, functions, transitions, and patterns
Build web radio pipelines with confidence
No hallucinations. No version drift. No mystery errors.
Liquidsoap is incredibly powerful, but:
Documentation varies heavily between versions
1.x and 2.x syntax differs in subtle ways
LLMs blend outdated examples into their answers
Even the official docs are spread across sections, pages, and changelogs
This MCP server gives your AI one job:
Stick to Liquidsoap 2.4.0 exactly.
It exposes a clean, structured API around the official docs so your assistant becomes a reliable Liquidsoap expert.
Full language reference
Core API functions & operators
Protocols (Icecast, HLS, HTTP, SRT, etc.)
Encoder/decoder options
Runtime settings
Related MCP server: PineScript Docs
Search functions/operators by name or keyword
Search through examples, patterns, and cookbook items
Search 2.4.0 changelog & migration notes
Detect deprecated functions (e.g. null(), insert_metadata)
Warn about 1.x syntax
Highlight common design pitfalls
Ready-to-use snippets:
Crossfading
Fallback chains
Harbor live input
HLS output
Cron scheduling (cron.add, cron.parse)
Metadata rewriting
LUFS normalization
Blank detection
Multi-output pipelines
Docs cached and indexed for instant responses
No web requests needed once running
Ask:
“Explain what this Liquidsoap script does.”
“Add a fallback before the HLS output.”
“Show the docs for crossfade.”
“Fix deprecated functions in this script.”
“Rewrite this using Liquidsoap 2.4.0-style null.”
Your AI responds using only the pinned 2.4.0 docs.
Node.js ≥ 18
Any MCP-compatible client
npm install -g liquidsoap-mcp-servergit clone https://github.com/splinesreticulating/LiquidSoapMCP.git
cd LiquidSoapMCP
npm install
npm run buildmacOS:~/Library/Application Support/Claude/claude_desktop_config.json
Windows:%APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"liquidsoap": {
"command": "npx",
"args": ["-y", "liquidsoap-mcp-server"]
}
}
}{
"mcpServers": {
"liquidsoap": {
"command": "node",
"args": ["/absolute/path/to/LiquidSoapMCP/build/index.js"]
}
}
}{
"mcpServers": {
"liquidsoap": {
"command": "docker",
"args": ["run", "-i", "--rm", "liquidsoap-mcp-server"]
}
}
}Build the image:
docker build -t liquidsoap-mcp-server .get_version
list_sections
get_documentation(section)
search_functions(query)
get_changelog
get_examples(topic)
validate_script_syntax(script)
language
reference
protocols
settings
encoding_formats
ffmpeg
quickstart
cookbook
Liquidsoap script graph visualization
Integrate liquidsoap --check for full type validation
Multi-version switching (2.2.x, 2.3.x, etc.)
Fuzzy search & semantic function lookup
“Explain this error log” tool
Pattern/snippet library
PRs welcome. Especially:
More examples
Better search
Doc parsing improvements
Additional validation rules
MCP integration templates
Built for the Liquidsoap community, and for the DJs, webradio operators, self-hosters, and audio nerds who want Liquidsoap to be easier, safer, and more fun with AI assistance.
Please star the repo!
It helps others discover it and tells me this niche was worth carving out.
Get the changelog and breaking changes for LiquidSoap 2.4.0
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the action of getting data. It does not disclose any potential side effects, access requirements, caching behavior, or other non-obvious aspects. Since the tool is read-only in nature, transparency is minimal but not contradicted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear, concise, and free of unnecessary details. It is well-structured and directly conveys the core functionality without ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no complex output), the description is fully complete. It tells the user exactly what to expect—changelog and breaking changes—and does not omit any necessary information for invocation or understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100% by default. The description does not need to explain parameter semantics, but the baseline for no parameter info is 3, and there is no additional value added beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving the changelog and breaking changes for a specific version of LiquidSoap. The verb 'Get' is specific and the resource is well-defined, distinguishing it from sibling tools like get_version or get_documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need changelog or breaking changes), but it does not explicitly mention alternatives or situations when not to use it. Sibling tools exist, but no differentiation is provided, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a specific section of the LiquidSoap 2.4.0 documentation
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | Documentation section to fetch. Available: language, reference, protocols, settings, ffmpeg, quickstart, cookbook, encoding_formats | |
| max_length | No | Maximum length of returned content in characters (default: 50000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions 'Fetch', implying a read-only operation but not explicitly stating side effects, error handling, or rate limits. There is no transparency about behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words or repetition. It directly communicates the purpose and scope without extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema), the description is largely complete. However, it does not mention how errors (e.g., invalid section) are handled or what the returned content looks like, which could be useful for an agent, though not strictly required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters, including an enum for 'section' and a clear explanation for 'max_length'. The tool description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch') and the specific resource ('specific section of the LiquidSoap 2.4.0 documentation'). It implies distinction from siblings like list_sections (which would list sections) and search_functions (which searches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the sibling tools (e.g., list_sections for enumerating available sections, search_functions for finding a function). It simply states what the tool does without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get code examples for common LiquidSoap tasks
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Task to get an example for (e.g., 'crossfade', 'fallback', 'normalize', 'hls-output', 'harbor', 'cron', 'blank-detection', 'metadata', 'encoding-formats') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The phrase 'Get code examples' implies a safe, read-only operation, but it does not disclose any potential side effects, required permissions, or rate limits—though none are likely for such a tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is efficiently structured and immediately conveys the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the lack of an output schema, the description is sufficient for an agent to understand its purpose and primary input. It does not need extensive additional context, though a note on response format could marginally improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'task' is documented with a description listing example values (e.g., 'crossfade', 'fallback'), which helps the agent understand what to pass. However, it does not specify whether the input must be one of these exact strings or if other values are accepted, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving code examples for common LiquidSoap tasks. It uses a specific verb and resource, though it does not explicitly differentiate itself from sibling tools like get_changelog or get_documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It lacks statements like 'use this when...' or 'if you need...', leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the LiquidSoap version this server supports (2.4.0)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. The verb 'Get' strongly implies a read-only operation with no side effects, but the description does not explicitly state this or mention any authentication/rate limit considerations. It is sufficient but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with the verb and resource front-loaded. Every word earns its place; the parenthetical example adds clarity without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple version-getter with no input parameters and no output schema, the description is complete. It identifies the resource, the scope ('this server supports'), and even gives an example value. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema coverage is 100% and the baseline per the rubric is 4. The description adds no parameter info (there is none to add), and no further detail is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the exact resource ('LiquidSoap version this server supports'), and the parenthetical '(2.4.0)' provides a concrete example. It is clearly distinct from siblings like get_changelog or get_documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly states the purpose, making the appropriate usage obvious. However, it does not explicitly compare to alternatives or state when not to use it, unlike a stronger usage guideline that would mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available documentation sections with descriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It mentions the action and the result (list sections with descriptions) but does not disclose any potential issues such as pagination, authentication requirements, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is well-structured and immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema specified), the description is adequately complete for a basic listing action. However, it could benefit from briefly noting the expected output format or any potential limitations, such as missing sections or empty results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain any parameters, and it does not introduce any ambiguity about them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing all available documentation sections with descriptions. It uses a specific verb ('list') and resource ('documentation sections'), and distinguishes itself from sibling tools like get_changelog or get_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, without mentioning any conditions or scenarios that would make it the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for functions or operators in the LiquidSoap API reference
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term (function name, keyword, or description) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, side effects, or error conditions. The search action is implicitly non-destructive, but this is not stated explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and direct, with no unnecessary details. It is well-structured and immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for a simple search tool, but it does not mention what the response looks like (e.g., list of matching entries) or any limitations (e.g., pagination, result count). Given the absence of an output schema, additional context about return format would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'query' is clearly described with specific guidance on what constitutes a valid search term (function name, keyword, or description). This adds meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching for functions or operators in the LiquidSoap API reference. It is specific and distinguishes it from sibling tools that retrieve specific documents or list sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding functions/operators, but does not explicitly state when to prefer this over alternatives like list_sections or get_documentation. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide basic syntax validation and best practices for a LiquidSoap script
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | LiquidSoap script code to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only validation operation by saying 'provide syntax validation', but it does not explicitly state side effects, permissions, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately communicates the tool's purpose. It is concise and well-structured with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema, the description is mostly adequate, but it does not indicate what the tool returns (e.g., errors, warnings, best-practice suggestions). Since there is no output schema, a brief note about the result format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'script' parameter, and the parameter description repeats the tool's purpose. The tool description adds no further detail about expected input format, size, or edge cases, so it meets the baseline but adds little.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's function: providing basic syntax validation and best practices for a LiquidSoap script. It is distinct from sibling documentation tools like get_documentation or search_functions, which are retrieval-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: an agent would use this tool when it needs to validate a LiquidSoap script or receive best practices. However, there is no explicit guidance on when to prefer this tool over alternatives or 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_changelogget_documentationget_examplesget_versionlist_sectionssearch_functionsvalidate_script_syntaxScored across 7 tools
Each tool has a clearly distinct purpose: version info, changelog, documentation sections, function search, examples, section listing, and script validation. Even list_sections and get_documentation have a natural complementary relationship without overlap.
All tool names follow a consistent verb_noun snake_case pattern (get, list, search, validate), with no mixing of conventions or vague verbs. The naming is predictable and readable.
7 tools is well-scoped for a documentation and validation server. Each tool earns its place, covering the core use cases without redundancy or bloat.
The tool surface covers the domain comprehensively: version, changelog, documentation access, function lookup, examples, section navigation, and script validation. There are no obvious dead ends or missing operations for the stated purpose.
The documentation, as a tool your agent can call: 950+ AI-dev guides. Search + fetch tools.
AI-manageable audio CDN: upload, transcode, normalize, stream & deliver audio, plus grounded docs.
Control your internet radio from any AI client: listeners, stream, playlists, AutoDJ, DJs, store.
SIP/VoIP/telecom grounding for AI agents: vendor docs, RFCs, STIR/SHAKEN, traces, configs.
