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., "@Loxone MCP Server turn on the living room lights"
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.
A Model Context Protocol (MCP) server that connects AI assistants and IDEs to your Loxone smart home system. Control lights, blinds, climate, and scenes through natural language or code.
Device Control: Turn lights on/off, adjust dimmers, control blinds and climate
Scene Management: Trigger Loxone scenes and automation scenarios
Real-time Updates: Live device state monitoring via WebSocket
Secure Access: PIN-protected commands for security devices
Auto Discovery: Finds all your Loxone devices automatically
Related MCP server: Home Assistant MCP Server
Python 3.10+
Loxone Miniserver (Gen 1/2, firmware 10.0+)
Network access to your Miniserver
Valid Miniserver credentials
# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows (PowerShell)
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"# Clone and setup
git clone <repository-url>
cd loxone-mcp-server
# Install dependencies
uv venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
uv pip install -e ".[dev]"
# Run the server (no configuration needed)
uv run loxone-mcp-serverThe server is stateless and does not require environment credentials. Each MCP client provides credentials when calling tools.
Optional server configuration:
# Optional server settings
MCP_TRANSPORT=http # Set to 'http' for HTTP mode (default: 'stdio')
MCP_HOST=127.0.0.1 # HTTP host (default: '127.0.0.1')
MCP_PORT=8000 # HTTP port (default: 8000)
LOG_LEVEL=INFO # Logging levelThe server supports two transport modes:
For MCP clients like Claude Desktop that connect via stdio:
# Run with stdio transport (default)
uv run loxone-mcp-serverFor web-based clients or Amazon Q CLI that connect via HTTP:
# Run with HTTP transport
MCP_TRANSPORT=http uv run loxone-mcp-server
# Or use the dedicated HTTP command
uv run loxone-mcp-server-http
# Server will be available at: http://127.0.0.1:8000/mcpThe project includes a pre-configured Amazon Q CLI agent:
# Activate the agent (no credentials needed - provided per tool call)
q use agent loxone-smart-homeThe agent configuration is in .amazonq/cli-agents/loxone-agent.json and includes:
MCP server setup with uv runner
Allowed tools for safe operation
Resource access to docs and config files
Note: Credentials are now provided per tool call, not stored in settings.
To use Amazon Q CLI with HTTP transport, run the server in one console and configure Q CLI to connect via HTTP:
Console 1 - Start the HTTP server:
# Start HTTP server (no credentials needed)
MCP_TRANSPORT=http uv run loxone-mcp-server
# Server will show: "MCP endpoint will be available at: http://127.0.0.1:8000/mcp"Console 2 - Configure Amazon Q CLI:
# Create HTTP-based agent configuration
q agent create loxone-http --mcp-server http://127.0.0.1:8000/mcp
# Or modify existing agent to use HTTP endpoint
q settings set agent.loxone-smart-home.mcp_endpoint http://127.0.0.1:8000/mcp
# Use the agent
q use agent loxone-httpAdd to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"loxone": {
"command": "uv",
"args": ["--directory", "/path/to/loxone-mcp-server", "run", "loxone-mcp-server"]
}
}
}For HTTP mode, start the server separately and configure Claude Desktop to connect via HTTP:
Start the server in HTTP mode:
MCP_TRANSPORT=http uv run loxone-mcp-serverConfigure Claude Desktop for HTTP:
{
"mcpServers": {
"loxone": {
"url": "http://127.0.0.1:8000/mcp"
}
}
}Stdio mode: Use the command-line pattern shown above
HTTP mode: Connect to http://127.0.0.1:8000/mcp endpoint
The server provides these tools for AI assistants. All tools require Miniserver credentials as parameters:
loxone_list_devices - List all devices (requires: host, username, password)
loxone_get_device_state - Get current device state (requires: host, username, password, uuid)
loxone_set_switch - Turn switches on/off (requires: host, username, password, uuid, state)
loxone_set_dimmer - Control light brightness (requires: host, username, password, uuid, brightness)
loxone_set_cover_position - Control blinds/covers (requires: host, username, password, uuid, position)
loxone_set_temperature - Set climate target temperature (requires: host, username, password, uuid, temperature)
loxone_list_scenes - List available scenes (requires: host, username, password)
loxone_trigger_scene - Activate a scene (requires: host, username, password, uuid)
loxone_send_command - Send raw commands (requires: host, username, password, uuid, value)
loxone_send_secured_command - PIN-protected commands (requires: host, username, password, uuid, value, code)
Example usage:
"List devices on my Miniserver at 192.168.1.100 with username admin and password mypass"
"Turn on device uuid abc123 on Miniserver 192.168.1.100 with credentials admin/mypass"
# Install dependencies
uv pip install -e ".[dev]"
# Setup pre-commit hooks (optional but recommended)
make setup-pre-commit# Run all CI checks locally
make ci-check
# Individual commands
make test # Run tests with coverage
make lint # Check code with ruff
make format # Format code with black
make type-check # Type check with mypy# Integration tests now use credentials passed to tools
uv run pytest tests/integration/# Start server in HTTP mode (no credentials needed)
MCP_TRANSPORT=http uv run loxone-mcp-server
# In another terminal, test the endpoint
curl -X POST http://127.0.0.1:8000/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc": "2.0", "id": 1, "method": "ping"}'Connection Failed
Check Miniserver IP and credentials
Verify network connectivity: ping <miniserver-ip>
Ensure ports 80/443 are accessible
Authentication Failed
Verify username/password in Loxone Config
Delete token file and restart: rm loxone_token.json
Check user permissions in Loxone Config
Device Not Found
Restart server to reload device structure
Check device UUID in Loxone Config
Ensure device is not hidden/disabled
Debug Logging
export LOG_LEVEL=DEBUG
uv run loxone-mcp-serverMIT License - see LICENSE file for details.
Get comprehensive state information for a specific Loxone device.
Returns detailed device state including all available parameters, capabilities, metadata, and device-type specific state structures. This enhanced version provides complete state information with parameter descriptions, units, and validation rules.
Args: uuid: The UUID of the device host: Loxone Miniserver host/IP address (uses LOXONE_HOST env var if not provided) username: Loxone username (uses LOXONE_USERNAME env var if not provided) password: Loxone password (uses LOXONE_PASSWORD env var if not provided) port: Loxone port (uses LOXONE_PORT env var or default: 80) client_id: Unique identifier for the client (default: "default")
Returns: Comprehensive device state response including: - Basic device information (uuid, name, type, room, category) - Enhanced state structure with device-type specific parameters - Device capabilities and supported operations - State parameter metadata (descriptions, units, ranges) - State validation rules and default values - Cache status and update tracking information
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | Yes | ||
| host | No | ||
| username | No | ||
| password | No | ||
| port | No | ||
| client_id | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It does not mention side effects, permissions, rate limits, or auth requirements beyond parameter defaults. Only configuration details are given.
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 well-structured with sections for summary, arguments, and return values. It is slightly lengthy but each sentence adds value, making it appropriate.
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?
While the description covers parameters and return structure well given the output schema, it lacks context about using this tool with sibling tools (e.g., needing a UUID from loxone_list_devices) and error handling.
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 0%, but the 'Args' section provides meaningful descriptions for all 6 parameters, including defaults and env var fallbacks, adding value beyond schema types.
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 it gets comprehensive state information for a specific Loxone device, distinguishing it from sibling tools with different purposes (listing devices, testing connections). The verb and resource are specific.
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 does not explicitly state when to use this tool versus alternatives like loxone_list_devices or loxone_test_connection. Usage is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Loxone devices with optional filtering.
Args: host: Loxone Miniserver host/IP address (uses LOXONE_HOST env var if not provided) username: Loxone username (uses LOXONE_USERNAME env var if not provided) password: Loxone password (uses LOXONE_PASSWORD env var if not provided) port: Loxone port (uses LOXONE_PORT env var or default: 80) client_id: Unique identifier for the client (default: "default") device_type: Filter by device type (e.g., "Switch", "Dimmer", "Jalousie") room: Filter by room name
Returns: Standardized response with list of devices and their basic information
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| username | No | ||
| password | No | ||
| port | No | ||
| client_id | No | default | |
| device_type | No | ||
| room | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses authentication via environment variables and mentions a standardized response. However, it does not detail error behavior, connection handling, or rate limits.
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 well-structured with a bullet list of parameters and defaults. It is reasonably concise but could be slightly more compact.
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 complexity (7 optional parameters) and existence of an output schema, the description provides adequate context. It explains env var fallback and filtering, though it could mention that return values are detailed in the output schema.
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?
Input schema has 0% description coverage, so the description compensates by listing parameters with brief explanations. However, 'client_id' is not explained, and 'device_type' and 'room' could use examples.
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: 'List all Loxone devices with optional filtering.' This is a specific verb+resource combination that distinguishes it from sibling tools like 'loxone_get_device_state' and 'loxone_test_connection'.
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 clear context by noting that parameters can be omitted and fall back to environment variables. It implies when to use (listing devices) versus siblings, but does not explicitly exclude cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test connection to Loxone Miniserver.
Args: host: Loxone Miniserver host/IP address (uses LOXONE_HOST env var if not provided) username: Loxone username (uses LOXONE_USERNAME env var if not provided) password: Loxone password (uses LOXONE_PASSWORD env var if not provided) port: Loxone port (uses LOXONE_PORT env var or default: 80)
Returns: Connection test result
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | ||
| username | No | ||
| password | No | ||
| port | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It mentions env var fallbacks but lacks details on side effects, error handling, or exact behavior of the test.
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 concise docstring with clear sections for Args and Returns, providing all necessary information without extraneous text.
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 covers parameters and purpose well, but lacks details about the output schema content, though an output schema exists to fill that gap.
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?
With 0% schema description coverage, the description adds significant value by explaining each parameter's meaning, env var fallback, and default port, which the schema does not provide.
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 explicitly states 'Test connection to Loxone Miniserver,' which is a specific action distinct from siblings like loxone_get_device_state and loxone_list_devices.
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 explicit guidance on when to use this tool versus alternatives, but the purpose implies it is for testing connectivity before performing other operations.
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.
v0.3.10loxone_get_device_stateloxone_list_devicesloxone_test_connectionEach tool targets a distinct action: listing devices, getting a single device state, and testing connection. There is no overlap in functionality.
All tools follow the consistent loxone_verb_noun pattern (loxone_list_devices, loxone_get_device_state, loxone_test_connection).
With 3 tools, the server is slightly underpopulated but still reasonable for basic read and connectivity operations. Could benefit from a few more tools.
The server lacks control/update operations (e.g., setting device state, dimming), which are essential for a home automation system. Only read and test are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Control your Tesla from your AI assistant - climate, charging, access, and security.
Manage digital signage screens, playlists and media from your AI assistant.
GDPR-compliant calendar access for AI assistants. Google, Microsoft 365, Apple & more. EU-hosted.
Connect Exact Online to your AI assistant via MCP. Manage Exact Online with natural language.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BernhardRode/loxone-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
