The Icecast MCP Server analyzes and optimizes Icecast streaming server configurations through automated audits and recommendations.
Core Capabilities:
Analyze Icecast XML configurations: Parse and validate configuration files to detect issues across security, performance, capacity, and reliability
Security auditing: Identify default credentials, missing authentication, weak relay passwords, and access control vulnerabilities
Performance analysis: Evaluate client limits, buffer sizes (queue/burst), thread pools, and log verbosity to identify bottlenecks
Capacity planning: Assess listener limits against expected loads and provide scaling recommendations
Reliability checks: Validate mount points, fallback configurations, and timeout settings for system resilience
Operational insights: Review hostname setup, proxy configurations (X-Forwarded-For), logging practices, and log rotation
Best practice recommendations: Receive deployment-specific guidance tailored for small (<50 listeners), medium (50-500 listeners), or large (500+ listeners) use cases
Prioritized reporting: Get structured output with CRITICAL, WARNING, and INFORMATION severity levels to prioritize fixes
Flexible deployment: Works with Claude Desktop, MCP Inspector, Docker, or any MCP-compatible client via stdio communication
Provides configuration validation for Icecast servers running behind Caddy reverse proxies, specifically checking X-Forwarded-For and hostname settings.
Parses and validates Icecast configuration files in XML format to identify security vulnerabilities, performance bottlenecks, and reliability issues.
Click on "Install 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., "@Icecast MCP Server analyze my icecast config at /etc/icecast.xml for 200 listeners"
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.
MCP server for analyzing and optimizing Icecast streaming server configurations.
Features • Installation • Usage • Tools • Docker
A Model Context Protocol (MCP) server for analyzing Icecast streaming server configurations. Provides automated security audits, performance recommendations, and capacity planning for internet radio stations and streaming infrastructure.
Features:
Security auditing (authentication, credentials, access control)
Performance analysis (limits, buffers, threading)
Capacity planning based on listener counts
Best practice recommendations for different deployment sizes
Related MCP server: Kastell
Parse and validate Icecast XML configurations
Detect security issues (default credentials, missing authentication)
Identify performance bottlenecks (buffer sizes, thread pools, limits)
Check reliability settings (timeouts, fallback mounts)
Validate proxy configurations (X-Forwarded-For, hostname)
Tailored advice for small, medium, and large deployments
Capacity planning based on expected listener counts
Security hardening guidelines
Performance tuning recommendations
Category | Checks |
Security | Authentication config, default credentials, relay passwords, admin security |
Performance | Client limits, buffer sizes (queue/burst), thread pools, log verbosity |
Capacity | Listener count vs. limits, resource allocation, scaling recommendations |
Reliability | Mount points, fallback configuration, timeout settings |
Operations | Hostname setup, proxy config, logging, log rotation |
git clone https://github.com/splinesreticulating/icecast-mcp.git
cd icecast-mcp
npm install
npm run builddocker build -t icecast-mcp .npm install -g icecast-mcpAdd to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"icecast": {
"command": "node",
"args": ["/absolute/path/to/icecast-mcp/build/index.js"]
}
}
}Or using Docker:
{
"mcpServers": {
"icecast": {
"command": "docker",
"args": ["run", "-i", "--rm", "-v", "/path/to/your/configs:/configs:ro", "icecast-mcp"]
}
}
}Test the server locally:
npm run build
npm run inspectorThe server communicates over stdio and follows the MCP specification. Compatible with any MCP client including Claude Desktop.
analyze_icecast_configAnalyze an Icecast XML configuration file and receive detailed recommendations.
Input Schema:
{
"configPath": "/path/to/icecast.xml",
"expectedListeners": 200
}Parameter | Type | Required | Default | Description |
| string | Yes | - | Absolute path to Icecast XML config |
| number | No | 100 | Expected concurrent listeners |
Example Usage:
Ask Claude: "Analyze my Icecast config at /etc/icecast2/icecast.xml for 500 expected listeners"Output Format:
# Icecast Configuration Analysis
Analyzing: /etc/icecast2/icecast.xml
Expected listeners: 500
## CRITICAL ISSUES
### Security: No authentication configured
Configure source-password and admin-password to secure your stream.
## WARNINGS
### Capacity: Client limit is quite low
Client limit is 50. This may cause connection rejections during peak times.
Current: 50
Recommended: 128
## INFORMATION
### Configuration: X-Forwarded-For is enabled
Good! This is correct when running behind a reverse proxy like Caddy.get_icecast_best_practicesGet deployment-specific best practices and configuration recommendations.
Input Schema:
{
"useCase": "medium"
}Parameter | Type | Required | Options | Description |
| string | Yes |
| Deployment size |
Use Case Definitions:
small: < 50 concurrent listeners
medium: 50-500 concurrent listeners
large: 500+ concurrent listeners
Example Usage:
Ask Claude: "What are the best practices for a medium-sized Icecast deployment?"Output: Comprehensive guide covering limits, security, mount points, performance, and reliability for your deployment size.
docker build -t icecast-mcp .docker run -i --rm \
-v /path/to/your/icecast/config:/config:ro \
icecast-mcpversion: '3.8'
services:
icecast-mcp:
build: .
volumes:
- ./ops/icecast:/config:ro
stdin_open: true
tty: true# Install dependencies
npm install
# Run in development mode (hot reload)
npm run dev
# Build TypeScript
npm run build
# Test with MCP Inspector
npm run inspector
# Run tests (if available)
npm testA typical workflow:
Install and configure icecast-mcp
Ask Claude: "Analyze my Icecast config at /etc/icecast2/icecast.xml for 200 listeners"
Get specific recommendations:
Optimize client limits for your traffic
Add relay password configuration
Configure fallback mount points
Enable log archiving
┌─────────────────┐
│ MCP Client │ (Claude Desktop, etc.)
│ (AI Assistant) │
└────────┬────────┘
│ stdio
│
┌────────▼────────┐
│ icecast-mcp │
│ MCP Server │
├─────────────────┤
│ • XML Parser │
│ • Analyzer │
│ • Validator │
│ • Recommender │
└────────┬────────┘
│
▼
icecast.xmlContributions welcome! Areas for improvement:
Additional analysis rules
Support for more Icecast features
Performance metrics integration
Live server monitoring
Configuration generation
MIT License - see LICENSE file for details.
Built with @modelcontextprotocol/sdk
Analyze an Icecast XML configuration file and provide recommendations for improvements. Checks security, performance, capacity, and reliability settings.
| Name | Required | Description | Default |
|---|---|---|---|
| configPath | Yes | Path to the Icecast XML configuration file | |
| expectedListeners | No | Expected number of concurrent listeners (optional, default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool analyzes and provides recommendations, but does not mention that it is read-only, what permissions might be needed, or any potential side effects. The description is adequate but lacks detail.
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 consists of two concise sentences that immediately convey the primary action and scope. Every sentence adds value without redundancy.
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 output schema, two parameters) and lack of annotations, the description is fairly complete: it identifies the file type, the action, and the areas of analysis. However, it could be improved by specifying the output format or nature of recommendations.
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 has 100% description coverage for both parameters, so the schema already explains their meaning. The tool description itself does not elaborate on the parameters, but given the schema coverage, it does not need to. 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 verb 'Analyze' and the resource 'Icecast XML configuration file', and specifies the areas of improvement (security, performance, capacity, reliability). This distinguishes it from the sibling tool 'get_icecast_best_practices', which likely provides general best practices rather than analyzing a specific file.
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 that the tool should be used when you have a specific Icecast configuration file to analyze, but it does not explicitly state when to use it versus the sibling tool 'get_icecast_best_practices'. No guidance on prerequisites or when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get general best practices and recommendations for Icecast configuration based on use case
| Name | Required | Description | Default |
|---|---|---|---|
| useCase | Yes | Use case: 'small' (< 50 listeners), 'medium' (50-500 listeners), 'large' (500+ listeners) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states the function is to 'get' recommendations, which implies a read-only operation, but does not detail any side effects, data source, or operational constraints. The description adds minimal value beyond the schema.
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 redundancy. It is front-loaded but very brief. While efficient, it could benefit from a slight expansion to include behavioral or usage context without sacrificing conciseness.
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 has one parameter, no output schema, and no annotations, the description provides the minimum viable information. It explains what the tool does but does not specify the format or structure of the returned recommendations, leaving gaps for an agent to interpret correctly.
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 description coverage is 100% with a detailed description for the 'useCase' parameter including enum values and listener ranges. The tool description ('based on use case') does not add meaning beyond the schema, so the 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 ('Get'), the resource ('general best practices and recommendations for Icecast configuration'), and the condition ('based on use case'). It effectively distinguishes from the sibling tool 'analyze_icecast_config', which implies a focus on specific config analysis versus general recommendations.
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 obtaining best practices by use case but does not explicitly state when to use this tool versus its sibling or alternatives. No 'when not to use' guidance is provided, leaving the decision to the agent's inference.
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. Dates show when Glama detected each change.
analyze_icecast_configget_icecast_best_practicesThe two tools have clearly distinct purposes: one analyzes a specific configuration file, while the other provides general best practices. There is no overlap or ambiguity.
Both tool names follow the same verb_noun pattern with descriptive prefixes (analyze_icecast_config, get_icecast_best_practices), maintaining full consistency.
With only 2 tools, the server feels thin for its stated purpose. While the tools are focused, a broader scope (e.g., validation, editing) would justify more tools, but it's borderline acceptable.
The tools cover analysis and best practices, but lack validation, comparison, or modification capabilities. This leaves notable gaps for a comprehensive configuration tool.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security, SEO and AI-visibility scanner for web apps · free scans and focused checks via MCP.
AI website audit: security, SEO, performance, UX and accessibility checks with actionable fixes.
Scan any website or MCP server for agent readiness: 0-100 score, a fix per failing check. Free.
Authorized security, SEO, AI visibility, integrations, accessibility and performance audits.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/splinesreticulating/icecast-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
