Vertica 26.3.x – MCP server

Admin: Installing the MCP server RPM

Mon, 01 Jan 0001 00:00:00 +0000

The Vertica MCP server RPM cannot be installed on a host that has Vertica installed, whether Vertica is running or not. Install the MCP server on a dedicated host outside the Vertica cluster. An existing Vertica database cluster is not required at RPM installation time, but you must specify the required connection information before the MCP server can connect to the database.

Upgrading from a bundled MCP server to a standalone MCP server

Vertica version 26.2 and earlier bundle the MCP server with the database. To upgrade to the 26.3 standalone MCP server from an earlier release:

Upgrade the Vertica cluster to version 26.2.0-1.
On a host that does not have Vertica installed, install the MCP server RPM by following the steps described here.

Installing the MCP server

As root or with sudo, install the vertica-mcp-server RPM:
```
MCP_OWNER_USER=mcpuser rpm -Uvh --replacepkgs --ignoresize mcp_server_rpm
```
where mcp_server_rpm is the RPM path and filename, for example /tmp/vertica-mcp-server-26.3.0-0.x86_64.rpm.

MCP_OWNER_USER sets the operating system user that owns the MCP server installation. The default value is mcpuser. Use --owner-user to specify a different user.

On success, you should see the following output:
```
Installed MCP binary to /opt/vertica/bin/vertica_mcp_server
Ensured log directory exists at /opt/vertica/log
Set ownership to mcpuser:mcpuser
```
The installation process runs a compatibility check with the Vertica cluster. The check is skipped if the cluster is not reachable or the cluster URL is not provided at installation time.
Confirm the installed RPM version:
```
rpm -qa vertica-mcp-server
```
The output shows the installed version, for example:
```
vertica-mcp-server-26.3.0-0.x86_64
```
Switch to the MCP user:
```
su - mcpuser
```
Caution
You must switch to the MCP user before starting the MCP server for the first time. Starting the server as root sets incorrect permissions on /opt/vertica/config and /opt/vertica/log. If you start the server as root, you must manually correct permissions on those directories before the MCP user can start the server.

View the contents of the MCP server configuration file:

cat /opt/vertica/config/mcp_server.yaml

The file contains default values after a fresh installation, for example:

# MCP Server Configuration File
# This file was auto-generated with default values
#
# Configuration priority (highest to lowest):
# 1. Environment variables (MCP_*)
# 2. This YAML file
# 3. Built-in defaults
#
# For environment variable overrides, use:
# MCP_SERVER_ADDR, MCP_LOG_DIR, MCP_SSL_BASE_PATH, etc.
#

server_addr: :8667
read_timeout: 15s
write_timeout: 1m40s
idle_timeout: 1m0s
shutdown_timeout: 30s
max_header_bytes: 1048576
ssl_base_path: /opt/vertica/config/mcp_server
ssl_cert_path: /opt/vertica/config/mcp_server/server.pem
ssl_key_path: /opt/vertica/config/mcp_server/server.key
ca_cert_path: /opt/vertica/config/mcp_server/ca.pem
ca_key_path: /opt/vertica/config/mcp_server/ca.key
use_pg_client: false
vertica_host: vnode1
vertica_port: "5433"
vertica_dbname: ""
vertica_sslmode: require
query_timeout: 20s
max_query_rows: 10000
storage_type: leveldb
storage_path: /opt/mcp_storage/userdb
vcluster_enabled: true
vcluster_server_url: https://vnode1:8665
vcluster_cert_path: /opt/vertica/config/vcluster_server/admin.pem
vcluster_key_path: /opt/vertica/config/vcluster_server/admin.key
vcluster_ca_cert_path: /opt/vertica/config/vcluster_server/ca.pem
vcluster_skip_tls_verify: true
vcluster_nodes_cache_ttl: 5m0s
log_dir: /opt/vertica/log
max_active_jobs: 5
max_running_jobs: 3
max_finished_jobs: 50
finished_job_retention: 240h0m0s
query_tree_retention: 8760h0m0s
external_url: ""
node_host_overrides:
    192.168.1.101: vnode1
    192.168.1.102: vnode2
    192.168.1.103: vnode3
    192.168.1.104: vnode4
job_queue_path: /opt/mcp_storage/job_queue

Edit the following fields in mcp_server.yaml:
```
vi /opt/vertica/config/mcp_server.yaml
```
- vertica_host: The hostname or IP address of the Vertica database server.
- vertica_dbname: The name of the Vertica database to connect to.
- vcluster_server_url: The URL of the VCluster Web Service, for example https://<vcluster_server_node>:8665.
Note
If you are upgrading from a previous bundled MCP server deployment, you can use your existing mcp_server.yaml config file instead of manually editing the default values.

Copy the VCluster server SSL certificate files to the MCP server host.

scp -r <vcluster-server-node>:/opt/vertica/config/vcluster_server/admin.pem <mcp-server-node>:/opt/vertica/config/vcluster_server/
scp -r <vcluster-server-node>:/opt/vertica/config/vcluster_server/admin.key <mcp-server-node>:/opt/vertica/config/vcluster_server/
scp -r <vcluster-server-node>:/opt/vertica/config/vcluster_server/ca.pem <mcp-server-node>:/opt/vertica/config/vcluster_server/

Start the MCP server:
```
/opt/vertica/bin/manage_mcp_server.sh start mcp_server
```
On success, you should see output similar to the following:
```
Doing action start
Starting MCP server
Started MCP server with PID 874791
MCP server startup verified successfully
```
Verify that the MCP server binary exists at /opt/vertica/bin/vertica_mcp_server and certificate files exist at /opt/vertica/config/mcp_server.
Generate a JWT token for the MCP server. For more information about JWT token generation options, see MCP server.
```
/opt/vertica/bin/vertica_mcp_server --generate-token --userid user_id --dbpass password
```
Copy the JWT token string from the output of the previous command.
Update your AI agent configuration with the JWT token and the MCP server URL. The steps required depend on the type of agent you are using.

For an example using Claude Desktop, see Claude Desktop example.

The MCP server URL has the following format: https://<mcp_server_node>:8667/mcp

The AI agent can now connect to the database and query data.

Starting and stopping the MCP server

Switch to the MCP user and run the following command to start the MCP server:

/opt/vertica/bin/manage_mcp_server.sh start mcp_server

To stop the MCP server:

/opt/vertica/bin/manage_mcp_server.sh stop mcp_server

Uninstalling the MCP server

To uninstall the MCP server:

rpm -e vertica-mcp-server

To verify uninstallation:

rpm -qa | grep -i vertica-mcp-server

After uninstallation, the MCP server binary is removed from /opt/vertica/bin. The configuration .yaml file and log files are preserved.

Admin: MCP server environment variables

Mon, 01 Jan 0001 00:00:00 +0000

The Vertica MCP server is configured through a YAML configuration file and environment variables, with the following order of precedence:

Environment variables
YAML configuration file (default path: /opt/vertica/config/mcp_server.yaml)
Built-in defaults

The following sections list the available environment variables and their corresponding YAML keys, grouped by area: server, TLS/SSL, database, storage and secrets, VCluster server, and job queue settings.

Note

Duration values (timeouts, TTLs, and retentions) accept Go duration strings, such as 30s, 5m, 1h30m, or 240h.

Server settings

These variables control the HTTP server's network and request-handling behavior.

Environment variable	YAML key	Default value	Description
`MCP_SERVER_ADDR`	`server_addr`	`:8667`	Listen address for the MCP server (for example, `:8667`).
`MCP_READ_TIMEOUT`	`read_timeout`	`15s`	Maximum duration to read a full HTTP request.
`MCP_WRITE_TIMEOUT`	`write_timeout`	`100s`	Maximum duration to write an HTTP response.
`MCP_IDLE_TIMEOUT`	`idle_timeout`	`60s`	Maximum idle time on keep-alive connections.
`MCP_SHUTDOWN_TIMEOUT`	`shutdown_timeout`	`30s`	Maximum wait time for graceful server shutdown.
`MCP_MAX_HEADER_BYTES`	`max_header_bytes`	`1048576` (1 MB)	Maximum bytes parsed from request headers.
`MCP_LOG_DIR`	`log_dir`	`/opt/vertica/log`	Directory where server log files are written.
`MCP_EXTERNAL_URL`	`external_url`	(empty)	External base URL for building download links (for example, profile exports and query trees). Set this when the server runs behind Docker, proxies, or firewalls so that generated links are reachable from outside.

TLS/SSL settings

The MCP server requires TLS. If it does not find a certificate/key pair at startup, it automatically generates a self-signed CA and server certificate.

Note

MCP_SSL_BASE_PATH is applied first. Individual certificate paths (MCP_SSL_CERT_PATH, and so on) override the paths derived from the base path.

Environment variable	YAML key	Default value	Description
`MCP_SSL_BASE_PATH`	`ssl_base_path`	`/opt/vertica/config/mcp_server`	Base directory for TLS files. Certificate and key paths are derived from this if not set individually.
`MCP_SSL_CERT_PATH`	`ssl_cert_path`	`<ssl_base_path>/server.pem`	Path to the TLS server certificate (PEM format).
`MCP_SSL_KEY_PATH`	`ssl_key_path`	`<ssl_base_path>/server.key`	Path to the TLS server private key.
`MCP_CA_CERT_PATH`	`ca_cert_path`	`<ssl_base_path>/ca.pem`	Path to the root CA certificate for client verification.
`MCP_CA_KEY_PATH`	`ca_key_path`	`<ssl_base_path>/ca.key`	Path to the CA private key.

Database settings

These variables configure the connection to the Vertica database.

Note

VERTICA_HOSTS accepts a comma-separated list of hostnames (for example, host1,host2,host3). Duplicate entries are automatically removed.

Environment variable	YAML key	Default value	Description
`VERTICA_HOST`	`vertica_host`	`localhost`	Vertica host to which the MCP server connects.
`VERTICA_PORT`	`vertica_port`	`5433`	Vertica server port.
`VERTICA_DBNAME`	`vertica_dbname`	(empty — server default)	Database name. If empty, the server's default database is used.
`VERTICA_SSLMODE`	`vertica_sslmode`	`disable`	TLS mode for the Vertica connection. Accepted values are `disable`, `require`, `verify-ca`, and `verify-full`. This setting is not supported by the native Vertica client (the default client); if you use the native client, set it to `disable`.
`MCP_USE_PG_CLIENT`	`use_pg_client`	`false`	Use the PostgreSQL wire protocol client instead of the native Vertica client.
`MCP_QUERY_TIMEOUT`	`query_timeout`	`20s`	Maximum duration for a single database query.
`MCP_MAX_QUERY_ROWS`	`max_query_rows`	`10000`	Maximum rows returned per query to prevent runaway result sets.
`MCP_USE_LOAD_BALANCING`	`use_load_balancing`	`false`	Enable connection load balancing for the Vertica native client.

Storage and secrets

These variables control how user credentials are stored and internal secrets are managed.

Note

MCP_JWT_SECRET is sensitive. Never store it in the YAML file. Always supply it as an environment variable.

Environment variable	YAML key	Default value	Description
`MCP_STORAGE_TYPE`	`storage_type`	`leveldb`	Backend used to store credentials. Accepted values are `leveldb` and `memory`.
`MCP_STORAGE_PATH`	`storage_path`	`/opt/vertica/config/mcp_server/userdb`	Filesystem path for the LevelDB database directory.
`MCP_STORAGE_ENCRYPTION_KEY`	(internal)	(derived from server key)	32-byte AES key for encrypting passwords at rest. If not set, a key is automatically derived from the server private key file using SHA-256.
`MCP_JWT_SECRET`	(internal)	(derived from server key)	HMAC secret used for signing and verifying API key JWTs. Derived from the server key at startup if not explicitly set.

VCluster server settings

These variables configure integration with VCluster server, which provides cluster-management tools.

Note

If the client certificate or private key at the configured paths is missing or invalid, VCluster tools are automatically disabled at startup.

Environment variable	YAML key	Default value	Description
`MCP_VCLUSTER_ENABLED`	`vcluster_enabled`	`true`	Enable or disable VCluster server tools.
`MCP_VCLUSTER_SERVER_URL`	`vcluster_server_url`	`https://localhost:8665`	Base URL of the VCluster server API.
`MCP_VCLUSTER_CERT_PATH`	`vcluster_cert_path`	`/opt/vertica/config/vcluster_server/admin.pem`	Path to the client certificate for authenticating with VCluster server.
`MCP_VCLUSTER_KEY_PATH`	`vcluster_key_path`	`/opt/vertica/config/vcluster_server/admin.key`	Path to the private key for the VCluster server client certificate.
`MCP_VCLUSTER_CA_CERT_PATH`	`vcluster_ca_cert_path`	`/opt/vertica/config/vcluster_server/ca.pem`	CA certificate for verifying the VCluster server TLS certificate. Leave this empty to use system defaults.
`MCP_VCLUSTER_SKIP_TLS_VERIFY`	`vcluster_skip_tls_verify`	`true`	When `true`, skips TLS server verification for VCluster connections. Enabled by default; set to `false` in production to enforce verification.
`MCP_VCLUSTER_NODES_CACHE_TTL`	`vcluster_nodes_cache_ttl`	`5m`	How long the node topology is cached before a refresh is triggered.

Job queue settings

These variables tune the server's internal asynchronous job queue for long-running operations.

Environment variable	YAML key	Default value	Description
`MCP_MAX_ACTIVE_JOBS`	`max_active_jobs`	`50`	Total queue capacity, including both pending and running jobs.
`MCP_MAX_RUNNING_JOBS`	`max_running_jobs`	`10`	Maximum number of concurrently running jobs.
`MCP_MAX_FINISHED_JOBS`	`max_finished_jobs`	`100000`	Maximum number of completed job records retained for status queries.
`MCP_FINISHED_JOB_RETENTION`	`finished_job_retention`	`240h` (10 days)	How long completed job records are kept before they are removed.
`MCP_QUERY_TREE_RETENTION`	`query_tree_retention`	`8760h` (1 year)	How long the generated query tree HTML files are kept before automatic cleanup.

Admin: Claude Desktop example

Mon, 01 Jan 0001 00:00:00 +0000

This page provides examples for configuring the Vertica MCP server with Claude Desktop.

Configuring MCP server with Claude Desktop

Claude Desktop can connect to your MCP server to enable database query capabilities within Claude conversations.

Prerequisites

Claude Desktop installed (latest version).
MCP server running and accessible.
Valid JWT token for authentication.
Certificates to access VCluster server from the database administrator. For database adminstrators, the default certificates are located at /opt/vertica/config/vcluster_server/.
NPX tool mcp-remote (npm install -g mcp-remote).

Configuration

The Claude Desktop configuration file location varies by OS:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Edit the configuration file and add your MCP server. Example configuration:

{
  "mcpServers": {
    "vertica-mcp-server": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://<mcp_server_node>/mcp",
        "--insecure",
        "--tls-skip-verify",
        "--cert",
        "<path_to_certificate>\\admin.pem",
        "--key",
        "<path_to_key_file>\\admin.key",
        "--ca-cert".
        "<path_to_ca_cert>\\ca.pem",
        "--header",
        "X-API-Key:${API_KEY_VALUE}"
        ],
      "env": {
        "NODE_TLS_REJECT_UNAUTHORIZED": "0",
        "API_KEY_VALUE": "replace with your API key"
      }
    }
  }
}

where

<path_to_certificate> is the path to the admin.pem file, such as "C:\Users\username\vcluster_server\admin.pem". <path_to_key_file> is the path to the admin.key file, such as "C:\Users\username\vcluster_server\admin.key". <path_to_ca_cert> is the path to the ca.pem file, such as "C:\Users\username\vcluster_server\ca.pem".

Verifying the configuration

Restart Claude Desktop after saving the configuration (make sure kill all background processes)
Check Claude's MCP status - look for your server in the MCP panel
Test with a simple query:
```
SELECT version()
```

Admin: Curl examples

Mon, 01 Jan 0001 00:00:00 +0000

This page provides curl examples for testing and automating interactions with the Vertica MCP server. This is provided as a developer guide for interacting with the APIs.

Using the MCP server with curl

For testing and automation, you can interact with the MCP server directly using curl.

Basic request format

All MCP requests use JSON-RPC 2.0 format:

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: YOUR_JWT_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "method": "METHOD_NAME",
    "params": {
      "key": "value"
    },
    "id": 1
  }'

Initialize connection

First, initialize the MCP session:

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "jsonrpc": "2.0",
    "method": "initialize",
    "params": {
      "protocolVersion": "2024-11-05",
      "capabilities": {
        "roots": {
          "listChanged": true
        }
      },
      "clientInfo": {
        "name": "curl-client",
        "version": "1.0.0"
      }
    },
    "id": 1
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2024-11-05",
    "serverInfo": {
      "name": "vertica-mcp-server",
      "version": "1.0.0"
    },
    "capabilities": {
      "tools": {},
      "resources": {},
      "prompts": {}
    }
  }
}

List available tools

Discover what tools are available:

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/list",
    "params": {},
    "id": 2
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "tools": [
      {
        "name": "execute_query",
        "description": "Execute SQL queries against Vertica database",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": {
              "type": "string",
              "description": "SQL query to execute"
            },
            "subcluster": {
              "type": "string",
              "description": "Optional subcluster name"
            }
          },
          "required": ["query"]
        }
      },
      {
        "name": "submit_queue_query",
        "description": "Submit long-running query to job queue"
      },
      {
        "name": "list_jobs",
        "description": "List all jobs in the queue"
      }
    ]
  }
}

Execute a query

Run a simple SQL query:

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "execute_query",
      "arguments": {
        "query": "SELECT version()"
      }
    },
    "id": 3
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{\"columns\":[\"version\"],\"rows\":[{\"version\":\"Vertica Analytic Database v24.3.0-0\"}],\"count\":1}"
      }
    ]
  }
}

Execute query with subcluster routing

Route query to a specific subcluster:

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "execute_query",
      "arguments": {
        "query": "SELECT node_name, subcluster_name FROM nodes",
        "subcluster": "analytics_cluster"
      }
    },
    "id": 4
  }'

Submit long-running query to queue

For complex analytics queries that take longer to complete:

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "submit_queue_query",
      "arguments": {
        "query": "SELECT customer_id, SUM(amount) FROM sales GROUP BY customer_id",
        "description": "Monthly sales by customer"
      }
    },
    "id": 5
  }'

Response:

{
  "jsonrpc": "2.0",
  "id": 5,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Job submitted successfully. Job ID: 550e8400-e29b-41d4-a716-446655440000"
      }
    ]
  }
}

Check job status

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "get_job",
      "arguments": {
        "job_id": "550e8400-e29b-41d4-a716-446655440000"
      }
    },
    "id": 6
  }'

List all jobs

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "list_jobs",
      "arguments": {}
    },
    "id": 7
  }'

Cancel a job

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "cancel_job",
      "arguments": {
        "job_id": "550e8400-e29b-41d4-a716-446655440000"
      }
    },
    "id": 8
  }'

Health check

Check server health without authentication:

curl -k https://localhost:8667/health

Response:

{
  "status": "healthy",
  "total_pools": 3,
  "max_pools": 100
}

Using jq for pretty output

Format JSON responses with jq:

curl -k -X POST https://localhost:8667/mcp \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "execute_query",
      "arguments": {
        "query": "SELECT table_name FROM tables LIMIT 5"
      }
    },
    "id": 1
  }' | jq '.'

Bash script example

Create a reusable script for queries:

#!/bin/bash
# mcp_query.sh

API_KEY="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
SERVER="https://localhost:8667/mcp"
QUERY="$1"

if [ -z "$QUERY" ]; then
    echo "Usage: $0 'SQL QUERY'"
    exit 1
fi

curl -k -X POST "$SERVER" \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: $API_KEY" \
  -d "{
    \"jsonrpc\": \"2.0\",
    \"method\": \"tools/call\",
    \"params\": {
      \"name\": \"execute_query\",
      \"arguments\": {
        \"query\": \"$QUERY\"
      }
    },
    \"id\": 1
  }" | jq -r '.result.content[0].text'

Usage:

chmod +x mcp_query.sh
./mcp_query.sh "SELECT COUNT(*) FROM customers"

Admin: Query profiling

Mon, 01 Jan 0001 00:00:00 +0000

The Query Profiling feature in MCP server enables deep analysis of SQL queries, visualization of execution plans, and export of detailed query profile data. These tools help you understand query performance, resource usage, and execution flow across Vertica nodes and subclusters.

Key features

Profile storage in tables: Save query profiles in persistent tables within a specified schema, or use temporary tables for ad-hoc analysis.
Large Language Model (LLM)-driven analysis: Analyze queries using the MCP server's LLM, which processes operator statistics and performance aggregates (such as execution time and resource usage) computed by profiling tools.
Interactive plan tree visualization: Visualize query plan trees, including data flow volumes and execution times per node, with interactive HTML output.
Export/import profile data: Export all profile tables as a compressed tarball (.tar.gz) for sharing or offline analysis, and import them into other clusters or tools.
Subcluster and sandbox support: Profile query execution on specific subclusters or sandboxes by routing requests to the desired subcluster or sandbox.
Prompt support: Configure and execute analysis prompts with flexible input parameters to tailor profiling to your specific needs.

Profiling workflows

Query profiling supports two distinct workflows:

Profile and analyze using prompts – A guided, step-by-step approach where the LLM orchestrates the entire workflow, including job monitoring and analysis generation.
Direct tool access – Ask the LLM to use specific profiling tools directly without the built-in prompts, giving you fine-grained control over each step.

Both approaches produce the same profiling results that can be visualized, exported, and imported. Choose the approach that best fits your workflow.

Profile and analyze a query using prompts

Configure prompt inputs

In the LLM, click Add Connectors, select Add from vertica-mcp-server, and then click Analyze Query.
To begin profiling a SQL query, enter the required prompt details and click Add prompt:
- Mode: Set to new to execute and profile a new query, or existing to analyze a previously executed query by providing its transaction ID and statement ID.
- Query: The query you want to profile (for example, select avg(price) from sales;).
- Target_schema: The schema where results will be stored (for example, qprof1). A new schema is automatically created if it does not already exist.
- Key_id: A unique identifier for this profiling run (for example, k1). Profile table names have this ID appended (for example, qprof_query_profiles_k1).
- Transaction_id: The transaction id for an existing query.
- Statement_id: The statement id for an existing query.
- User_instructions: Additional instructions to customize the analysis.
- Analysis_scope: Specify the depth of analysis (basic or detailed). Defaults is basic.
- Subcluster: The subcluster where the query should be executed.
- Sandbox: The sandbox where the query should be executed. If both subcluster and sandbox are specified, sandbox is ignored.
Note
- Transaction ID and Statement ID: Provide Transaction_id and Statement_id to profile an already-executed query, or provide Query with Mode=new to execute and profile a new query. These fields are required when using Mode=existing, and should be left empty when using Mode=new.
- Key ID: If you leave the Key ID blank for mode existing, the system auto-generates a timestamp-based identifier. Using an explicit Key ID makes it easier to reference and retrieve your profiling results later.
Click analyze_query_text in the chat to view the analysis workflow and tools the LLM will use.

Review workflow steps

The analysis workflow displays the following steps:

Execute query: The qprof_execute tool runs the query with profiling enabled.
Generate job ID: A job_id is created to track the asynchronous execution.
Monitor completion: The LLM checks the job status once. If still running, it pauses and waits for your confirmation before checking again to prevent infinite loops.

Execute, monitor, and review analysis

When processing your analysis, the LLM performs these steps:

Submit and monitor: The job is submitted and checked for completion. If still running, the LLM pauses and requests confirmation before checking again.
Generate summary: Once the job completes, the LLM produces a comprehensive profile analysis, including performance assessment, key metrics (duration, success, queue wait time, nodes involved), bottleneck analysis, and optimization recommendations.

Profile storage

Profile data persists in the specified database schema and tables.

Analyze query profiles directly

Alternatively, you can ask the LLM to use specific profiling tools without the built-in prompts. This approach gives you direct control and works independently of the prompt-based workflow.

To use these tools, ask the LLM directly in the chat. For example, "Analyze this query profile using qprof_get_operator_stats" or "Get a summary of my query execution".

You can also analyze existing query profiles saved from previous runs. Provide the schema and key ID where the profile data is stored. For example: "Give me a summary of the query profile that is saved in the schema xyz with key slow_query". This is useful for analyzing historical query executions without re-executing them.

Available tools:

qprof_get_profile_summary: Get a high-level summary of the query execution, including duration, status, and resource usage.
qprof_get_events: Retrieve warnings, optimization hints, and execution issues.
qprof_get_resources: Examine resource pool acquisition details and queue wait times.
qprof_get_steps: See a detailed breakdown of execution phases and timing.
qprof_get_operator_stats: Analyze operator-level performance metrics (for example, slowest operators, memory usage).
qprof_get_path_stats: View aggregated statistics at the query plan path level.
qprof_get_plan: Get the raw EXPLAIN plan for the query.
qprof_get_plan_tree: Retrieve the complete query plan tree with structure, metrics, and operator details. This is best suited for LLM or programmatic analysis.

Each tool provides a focused view or set of metrics to help you understand and troubleshoot query performance.

Visualize, export, and import results

The following capabilities work with both profiling approaches above. Use them to interact with and share your profiling data.

Visualize query profile tree

You can visualize the query execution tree by asking the LLM to generate an interactive visualization:

Ask the LLM to visualize the query profile tree. Optionally, provide your MCP server IP and port.
The LLM generates an HTML file saved on the MCP server and provides a link to view it. To access the link, ensure you have network access to the MCP server's IP address and port (accounting for any port mappings in your environment).
Open the provided link in a browser to view the visualization.
The visualization tree displays all the details of the query profile. You can zoom in and out and interact with the query tree to analyze query execution.

Note

The query profile tree is generated as an HTML file on the MCP server rather than sent directly to your agent. This approach significantly reduces token usage. Alternatively, you can request an embedded object format to load the tree directly in agents such as Claude Desktop, though this option requires more tokens.

Export query profile data

You can export all profile tables as a compressed tarball (.tar.gz) for sharing or further analysis.

Ask the LLM to export the profiling data.
The system generates the profile export details and a download link for the profile tarball (.tar.gz).
Open the link in a browser to download the tarball (.tar.gz) to share or analyze offline.

Import and analyze query profiles

You can import profile data from other clusters or tools for analysis in your current environment. You can also import a tarball (.tar.gz) into VCluster using Query Profile and use the target schema and key ID to analyze using the MCP Server Query Profiling tools. For more information about Query Profile in the VCluster UI, see Query Profile.

Admin: Machine learning with the MCP server

Mon, 01 Jan 0001 00:00:00 +0000

The MCP server extends beyond SQL execution by providing integrated machine learning (ML) capabilities that support end-to-end data science workflows directly within the database. Using MCP tools and natural-language interaction, you can explore and prepare data, perform train-test splits, train and evaluate models, generate predictions, and interpret results without moving data out of Vertica or writing external code.

This in-database approach eliminates traditional ML pipeline complexity and preserves security and governance, while allowing you to iterate quickly through conversational, AI-assisted workflows. The integrated ML tools make advanced analytics accessible to both experienced data scientists and users with limited machine learning expertise, allowing them to build predictive models and derive actionable insights using simple natural-language prompts.

For users familiar with VerticaPy, the MCP server provides a no-code alternative for accessing similar in-database ML functionality without relying on VerticaPy or its associated dependencies.

For a complete reference of every ML tool, its input schema, and outputs, see ML tools reference.

Prerequisites

Before you run ML workflows, make sure the following requirements are met:

The MCP server is running and your AI client is connected. For installation, startup, JWT token generation, and role and privilege requirements, see MCP server.
Install the MachineLearningLib UDx library and the approximate package on the target database. These are required to run the ML tools. For installation steps, see install_packages.
The ML tools rely on in-database machine learning functions, which are available in both Enterprise Mode and Eon Mode. Some tools have additional version requirements. For example, ml_correlation_matrix uses CORR_MATRIX, which requires version 9.2.1 or later.

ML tools overview

The MCP server provides a comprehensive set of tools that support the complete machine learning lifecycle, from data preparation through model governance. These tools can be combined to build end-to-end ML workflows using natural language.

Data preparation and feature engineering

Tool	Description	Key parameters
`ml_apply_encoding`	Applies a previously fit encoder or label mapping to a new source table (for example, test or inference data), enforcing the same `NULL`/unseen-category sentinel policy used at fit time.	`table`, `columns`, `encoding_type`, `encoder_model_name` (for `one_hot`), `label_mapping_tables` (for `label`), `output_table`, `overwrite`, `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_apply_normalize`	Applies a previously fit normalization model to a new source table, producing a normalized output table (async).	`table`, `columns` (optional, for pre-flight validation), `model_name`, `output_table`, `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_encode_columns`	Encodes categorical columns into numeric representations. Persists encoder artifacts for later reuse on test/inference data.	`table`, `columns`, `encoding_type` (`one_hot` \| `label`), `output_table`, `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_impute`	Fills missing `NULL` values using a specified strategy. Results are materialized as a view (async).	`table`, `method` (`auto` \| `mean` \| `mode` \| `ffill` \| `bfill`), `columns`, `order_by` (required for `ffill`/`bfill`), `partition_columns`, `output_view`, `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_normalize`	Normalizes numeric columns and materializes the result as a view (async, no model persisted).	`table`, `columns`, `normalization_method` (`minmax` \| `zscore` \| `robust_zscore`), `output_view`, `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_normalize_fit`	Computes normalization parameters and persists them as a model in `v_catalog.models`. Optionally creates a normalized view. Use this when the same scaling must be applied consistently to train, test, and inference data.	`table`, `columns`, `normalization_method`, `model_name`, `output_view` (optional), `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_train_test_split`	Splits a source table into separate training and testing tables using a seeded random partition.	`table`, `test_ratio` (default: `0.3`), `seed` (default: `42`), `output_prefix`, `schema`, `subcluster` (optional), `sandbox` (optional)

Exploratory data analysis

Tool	Description	Key parameters
`ml_correlation_matrix`	Computes the pairwise correlation matrix for numeric columns. Uses `CORR_MATRIX` on Vertica 9.2.1 and later, with a fallback for older versions.	`table`, `columns` (optional; defaults to all numeric/boolean columns), `method` (`pearson` \| `spearman` \| `spearmand`), `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_detect_outliers`	Detects outliers in numeric columns using statistical thresholds. Read-only — no output table is created.	`table`, `columns`, `method` (`z_score` \| `robust_zscore` \| `iqr`), `threshold` (default: `3.0` for z/robust, `1.5` for iqr), `limit` (default: `100`), `schema`, `subcluster` (optional), `sandbox` (optional)

Model training

Tool	Description	Key parameters
`ml_cross_validate`	Evaluates an ML algorithm using k-fold cross-validation, with optional hyperparameter grid search. Submits an async job. Supported algorithms: `logistic_reg`, `linear_reg`, `naive_bayes`, `svm_classifier`, `svm_regressor`.	`algorithm`, `input_table`, `predictor_columns`, `target_column`, `model_name`, `fold_count` (default: `5`), `metrics`, `hyperparams`, `prediction_cutoff` (`logistic_reg` only), `params`, `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_train_model`	Trains Vertica in-database ML model. Submits an async job and returns a `job_id` immediately. Supported algorithms: `logistic_reg`, `naive_bayes`, `rf_classifier`, `svm_classifier`, `xgb_classifier`, `linear_reg`, `rf_regressor`, `xgb_regressor`, `svm_regressor`, `pls_reg`, `poisson_reg`, `kmeans`, `bisecting_kmeans`, `kprototypes`, `pca`, `svd`, `iforest`.	`algorithm`, `input_table`, `predictor_columns`, `target_column`, `model_name`, `num_clusters` (for k-means variants), `params`, `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_train_timeseries`	Trains a time-series model (ARIMA, AUTOREGRESSOR, or MOVING_AVERAGE). Supports univariate and multivariate (VAR) autoregressor models. Submits an async job.	`algorithm` (`arima` \| `autoregressor` \| `moving_average`), `input_table`, `timeseries_columns`, `timestamp_column`, `model_name`, `params`, `schema`, `subcluster` (optional), `sandbox` (optional)

Dimensionality reduction

Tool	Description	Key parameters
`ml_apply_pca`	Transforms data using a fitted PCA model and writes the principal component coordinates to an output table.	`table`, `columns`, `model_name`, `output_table` (optional; defaults to `mcp_pca_{table}_{timestamp}`), `num_components` (optional), `cutoff` (optional; cannot be combined with `num_components`), `match_by_pos` (optional), `key_columns` (optional), `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_apply_svd`	Applies a previously computed SVD model to a new data matrix and writes the transformed data to an output table.	`table`, `model_name`, `output_table`, `columns` (optional; defaults to all columns), `num_components` (optional), `exclude_columns` (optional), `key_columns` (optional), `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_pca`	Fits a PCA (Principal Component Analysis) model on a table and saves it in the Vertica model catalog.	`table`, `columns`, `model_name`, `num_components` (optional), `scale` (optional), `method` (optional; only `LAPACK`), `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_svd`	Performs Singular Value Decomposition (SVD) on a numeric data matrix and saves the model in `v_catalog.models`.	`table`, `model_name`, `columns` (optional; defaults to all columns), `num_components` (optional), `exclude_columns` (optional), `schema`, `subcluster` (optional), `sandbox` (optional)

Inference

Tool	Description	Key parameters
`ml_predict`	Runs predictions using a trained model and writes results to an output table.	`model_name`, `input_table`, `predictor_columns` (optional), `output_table`, `params`, `timestamp_column` (time-series), `num_predictions` (time-series, default: `10`), `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_predict_with_registered_model`	Runs predictions by referencing a registered model family name instead of a raw model name. Automatically resolves the production version unless a specific version is supplied.	`registered_name`, `registered_version` (optional), `input_table`, `predictor_columns` (optional), `output_table`, `use_classes`, `params`, `timestamp_column`, `num_predictions`, `schema`, `subcluster` (optional), `sandbox` (optional)

Model evaluation

Tool	Description	Key parameters
`ml_classification_report`	Computes accuracy, precision, recall, F1 score, and optionally AUC from a predictions table.	`table`, `actual_column`, `predicted_column`, `include_auc` (binary classification only), `probability_column` (required when `include_auc` is set), `schema`, `subcluster` (optional), `sandbox` (optional)
`ml_features_importance`	Computes normalized feature importance scores (0–100) from a trained model. Supports linear, tree-based, and time-series models.	`model_name`, `subcluster` (optional), `sandbox` (optional)
`ml_regression_report`	Computes regression metrics (MAE, MSE, RMSE, R², adjusted R², AIC, BIC, quantile errors) from a predictions table.	`table`, `actual_column`, `predicted_column`, `metrics` (optional list), `num_predictors` (default: `1`), `schema`, `subcluster` (optional), `sandbox` (optional)

Model registry and governance

Tool	Description	Key parameters
`ml_change_model_status`	Promotes or demotes a registered model version through the governance lifecycle.	`registered_name`, `registered_version`, `new_status` (`under_review` \| `staging` \| `production` \| `archived` \| `declined` \| `unregistered`), `subcluster` (optional), `sandbox` (optional)
`ml_get_model_status_history`	Fetches the native status-change audit history for a registered model from `v_monitor.model_status_history`.	`registered_name`, `registered_version` (optional), `subcluster` (optional), `sandbox` (optional)
`ml_get_production_model`	Resolves the current production version for a registered model family.	`registered_name`, `subcluster` (optional), `sandbox` (optional)
`ml_list_registered_models`	Lists registered model families and versions from `v_catalog.registered_models`.	`registered_name` (optional filter), `subcluster` (optional), `sandbox` (optional)
`ml_register_model`	Registers a trained native Vertica model under a registered model family name for lifecycle management.	`model_name`, `registered_name`, `schema`, `subcluster` (optional), `sandbox` (optional)

Note

ml_register_model registers a trained model and adds it to the Model versioning environment with a status of under_review. The model must be registered by the model owner, dbadmin, or a user with the MLSUPERVISOR role.

After a model is registered, the model owner is automatically changed to Superuser, and the previous owner is granted USAGE privileges. Users with the MLSUPERVISOR role or dbadmin can call ml_change_model_status to change the status of registered models.

Models cannot move freely between statuses. For the six possible statuses and a diagram of the valid transitions, see Model versioning.

Run an ML workflow using prompts

Use the guided Vertica ML Workflow prompt when you want the MCP server to plan and run a complete pipeline for you. You supply a few input fields, such as the algorithm, table, and target, and the MCP server orchestrates the remaining steps, from preprocessing through evaluation. For an illustration of the alternative conversational approach, where you drive each stage with individual natural-language requests, see the customer churn example in the next section.

Configure prompt inputs

In the LLM, click Connectors, select Add from vertica-mcp-server, and then click Vertica ML Workflow.
To begin with the ML workflow, enter the required prompt details and click Add prompt:
- Algorithm: Required. The machine learning algorithm to execute (for example, logistic_reg, rf_classifier, linear_reg, kmeans, pca, xgb_classifier, arima).
- Model_name: Override the auto-generated model name for saving in the Vertica catalog (for example, my_model). Auto-generated if omitted.
- Table: Source table or view name containing the dataset (for example, iris or public.iris).
- Target: Target or label column name for supervised learning (for example, Species). Omit for unsupervised algorithms like kmeans or pca.
- Features: Predictor columns as a comma-separated list (for example, SepalLengthCm, SepalWidthCm, PetalLengthCm, PetalWidthCm).
- Params: Algorithm hyperparameters as a JSON string with string values only (for example, {"max_iterations": "200"}).
- Schema: Default schema for unqualified table names (for example, public).
- Context: Additional instructions or execution flags to customize the workflow (for example, mode=cv, do not use temp table, use permanent table).
- Subcluster: The subcluster where tool calls should be routed.
- Sandbox: The sandbox where tool calls should be routed. If both subcluster and sandbox are specified, sandbox is ignored.
Click Vertica ML Workflow_text in the chat to view the ML workflow and tools the LLM will use.

Review workflow steps

Before making any tool calls, the LLM presents the plan it will follow. This workflow text includes:

Workflow configuration: The exact values used when filling tool arguments, such as the target column and the training algorithm.
Naming conventions: How generated artifacts are named, including the auto-generated model name, one-hot encoder and label-mapping tables, train/test split tables, and normalizer model.
NULL/unknown value policy: How missing inputs and unseen categories are handled for label encoding, one-hot encoding, and boolean columns.
Workflow steps: The ordered steps the LLM will run (for example, detect outliers, encode columns, normalize, split, train, and evaluate). Steps marked optional can be skipped when not applicable.

The LLM replies with a short plan first—one bullet per step, noting any skipped optional steps and the reason, and waits for your confirmation before it executes.

Execute, monitor, and review analysis

After you confirm the plan, the LLM executes the workflow. For each numbered step, it either runs the appropriate ML tool or skips the step when it does not apply to your data or algorithm, and it shows the reason for each decision.

Execute and monitor: The LLM runs each step in order, for example, the train/test split, model training, prediction, and evaluation. Heavy jobs run asynchronously, so the LLM polls each job with get_job_status and retrieves output with get_job_results, reporting progress as each stage completes.
Generate final summary: Once all steps finish, the LLM produces a final summary that reports the model name and location, the dataset and train/test split, evaluation metrics and feature importance along with a brief interpretation and any refinement recommendations.

As the LLM works through the plan, it reports each step and whether it ran or skipped it:

When all steps finish, the LLM compiles the results into a final summary:

The summary includes the model's performance metrics and confusion matrix:

It also reports the feature importance scores for the trained model:

End-to-end ML workflow: customer churn prediction

The following example demonstrates a complete customer churn analysis workflow using a simulated telecommunications dataset containing 1.2 million customer records and an approximate churn rate of 25%. The dataset includes intentionally introduced missing values and outliers to illustrate common data quality challenges encountered during real-world analysis.

Unlike the guided Vertica ML Workflow prompt, this example illustrates the conversational approach, where you drive each stage with individual natural-language requests. It uses a simulated dataset to show the kinds of prompts you can use and how the MCP server responds at each step.

Note

All heavy or time-consuming jobs run asynchronously in the background. The agent waits and periodically checks the job status, so it can continue with other work in the meantime.

The churn analysis follows a standard data science workflow:

Data exploration and cleaning
Pattern discovery and feature engineering
Data preparation
Model training
Model evaluation and interpretation

The MCP server automatically identifies and invokes the appropriate ML tools based on your requests throughout the workflow.

Step 1: Explore and clean data

The analysis begins by examining the dataset structure and reviewing sample records.

To start, ask the MCP server "Describe the churn_data table and show me a few sample rows."

It describes the table and displays example rows so you can understand available attributes, data types, and overall data quality.

Once you understand the data, address any quality issues. Ask "Find and impute any missing values in churn_data." The MCP server identifies missing values and automatically applies appropriate imputation strategies:

Numeric columns are typically filled using statistical methods such as mean imputation.
Categorical columns are filled using the most frequently occurring value (mode).

In this example, missing values in Monthly Charges were replaced with the column mean, while missing values in Payment Method were replaced with the most common payment type.

Step 2: Detect outliers and analyze relationships

After addressing missing data, ask "Check the numeric columns in churn_data for outliers."

Using the ml_detect_outliers tool, the MCP server highlights anomalous values and quantifies their impact on the dataset, allowing you to decide whether to investigate, remove, or retain these records.

In this example, it accurately identified the 1,133 outliers that were artificially created in the dataset.

Next, ask "Show me a correlation matrix for the numeric columns in churn_data."

The MCP server generates the matrix, visualizes the relationships between numeric variables, and identifies key drivers associated with churn.

In the churn analysis example, the strongest relationships with customer churn were found in:

Number of support calls (0.29)
Monthly charges (0.21)
Customer tenure (0.20)

These insights provide an initial understanding of the factors influencing customer retention.

Step 3: Feature engineering and data preparation

Machine learning models require numerical inputs. Categorical attributes such as Contract Type, Payment Method, and Internet Service must be encoded into model-ready numerical values. Ask "Encode the categorical columns in churn_data."

The MCP server automatically identifies categorical columns and performs the required encoding, transforming categories into numeric representations suitable for training.

The server can also normalize numeric features using standard scaling techniques, such as z-score normalization, ensuring that features operate on a comparable scale. This improves model performance and helps prevent bias toward variables with larger numerical ranges.

In this example, the tools successfully converted the numeric column to center around 0.

After preprocessing is complete, ask "Split churn_data into 70% training and 30% test sets."

In this example, the MCP server automatically selected a standard 70% training and 30% test split ratio for model development and validation.

Step 4: Train a machine learning model

After preparing the dataset, ask "Train a logistic regression model on the training data to predict churn." The MCP server trains a logistic regression model to predict customer churn.

During training, the server automatically generates feature importance information, providing immediate insight into which variables have the greatest influence on customer behavior.

Example findings included:

Feature	Impact on churn
Two-year contract	Reduces churn
One-year contract	Reduces churn
Number of support calls	Increases churn
Monthly charges	Increases churn
Customer tenure	Reduces churn

These feature importance metrics help explain model behavior and identify the most influential business factors.

Step 5: Evaluate the model

Ask "Evaluate the model on the test data and show me the classification metrics."

The trained model is evaluated against the testing dataset to measure predictive performance. In this example, the model achieved approximately 80% prediction accuracy despite the presence of simulated noise, missing values, and outliers.

The MCP server provides standard evaluation metrics, including:

Confusion matrix
Overall accuracy
Precision
Recall
F1 score
AUC (ROC)

These metrics enable you to assess model quality and determine whether additional refinement is required.

Interpret results and generate business insights

After evaluation, ask "Summarize the main drivers of churn and generate an executive summary." The MCP server summarizes the findings and identifies the primary drivers of customer churn.

Key conclusions from the churn analysis included:

Contract type was the strongest predictor of churn.
Customers with two-year contracts were significantly less likely to leave.
A high volume of support calls was a strong warning indicator of churn risk.
Higher monthly charges increased churn probability.
Longer customer tenure reduced churn likelihood.

To make results easier to consume, you can ask the MCP server to generate a business-friendly executive summary. The server produces a visual report that highlights:

Key churn drivers
Feature importance rankings
Recommended actions
Business-focused interpretations

This allows technical findings to be communicated effectively to business stakeholders and decision-makers.

Benefits of ML integration in the MCP Server

The machine learning tools integrated into the MCP server provide several advantages:

Enables end-to-end ML workflows through natural language interactions.
Eliminates dependency on VerticaPy for common ML tasks.
Supports automated data exploration, cleansing, and preparation.
Simplifies model training and evaluation.
Generates interpretable insights and executive-ready summaries.
Makes advanced analytics accessible to users with limited data science expertise.

Vertica 26.3.x – MCP server

Admin: Installing the MCP server RPM

Upgrading from a bundled MCP server to a standalone MCP server

Installing the MCP server

Caution

Note

Starting and stopping the MCP server

Uninstalling the MCP server

Admin: MCP server environment variables

Note

Server settings

TLS/SSL settings

Note

Database settings

Note

Storage and secrets

Note

VCluster server settings

Note

Job queue settings

Admin: Claude Desktop example

Configuring MCP server with Claude Desktop

Prerequisites

Configuration

Verifying the configuration

Admin: Curl examples

Using the MCP server with curl

Basic request format

Initialize connection

List available tools

Execute a query

Execute query with subcluster routing

Submit long-running query to queue

Check job status

List all jobs

Cancel a job

Health check

Using jq for pretty output

Bash script example

Admin: Query profiling

Key features

Profiling workflows

Profile and analyze a query using prompts

Configure prompt inputs

Note

Review workflow steps

Execute, monitor, and review analysis

Profile storage

Analyze query profiles directly

Visualize, export, and import results

Visualize query profile tree

Note

Export query profile data

Import and analyze query profiles

Admin: Machine learning with the MCP server

Prerequisites

ML tools overview

Data preparation and feature engineering

Exploratory data analysis

Model training

Dimensionality reduction

Inference

Model evaluation

Model registry and governance

Note

Run an ML workflow using prompts

Configure prompt inputs

Review workflow steps

Execute, monitor, and review analysis

End-to-end ML workflow: customer churn prediction

Note

Step 1: Explore and clean data

Step 2: Detect outliers and analyze relationships

Step 3: Feature engineering and data preparation

Step 4: Train a machine learning model

Step 5: Evaluate the model

Interpret results and generate business insights

Benefits of ML integration in the MCP Server