Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HYDROLIX_HOST | Yes | The hostname of your Hydrolix server | |
| HYDROLIX_PORT | No | The port number of your Hydrolix server. Usually doesn't need to be set unless using a non-standard port | 8088 |
| HYDROLIX_USER | Yes | The username for authentication | |
| HYDROLIX_VERIFY | No | Enable/disable SSL certificate verification. Set to "false" to disable certificate verification (not recommended for production) | true |
| HYDROLIX_DATABASE | No | Default database to use. Set this to automatically connect to a specific database | |
| HYDROLIX_PASSWORD | Yes | The password for authentication | |
| HYDROLIX_MCP_BIND_HOST | No | Host to bind the MCP server to when using HTTP or SSE transport. Set to "0.0.0.0" to bind to all network interfaces (useful for Docker or remote access). Only used when transport is "http" or "sse" | 127.0.0.1 |
| HYDROLIX_MCP_BIND_PORT | No | Port to bind the MCP server to when using HTTP or SSE transport. Only used when transport is "http" or "sse" | 8000 |
| HYDROLIX_MCP_SERVER_TRANSPORT | No | Sets the transport method for the MCP server. Valid options: "stdio", "http", "sse". This is useful for local development with tools like MCP Inspector | stdio |
Schema
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_databases | List available Hydrolix databases |
| list_tables | List available Hydrolix tables in a database |
| run_select_query | Run a SELECT query in a Hydrolix time-series database using the Clickhouse SQL dialect. Queries run using this tool will timeout after 30 seconds. The primary key on tables queried this way is always a timestamp. Queries should include either a LIMIT clause or a filter based on the primary key as a performance guard to ensure they return in a reasonable amount of time. Queries should select specific fields and avoid the use of SELECT * to avoid performance issues. The performance guard used for the query should be clearly communicated with the user, and the user should be informed that the query may take a long time to run if the performance guard is not used. When choosing a performance guard, the user's preference should be requested and used if available. When using aggregations, the performance guard should take form of a primary key filter, or else the LIMIT should be applied in a subquery before applying the aggregations. When matching columns based on substrings, prefix or suffix matches should be used instead of
full-text search whenever possible. When searching for substrings, the syntax Example query. Purpose: get logs from the
Example query. Purpose: get the median humidity from the
Example query. Purpose: get the lowest temperature from the
Example query. Purpose: get the app name with the most log messages from the |