mcp-vmanomaly

MCP Server for vmanomaly

The implementation of Model Context Protocol (MCP) server for vmanomaly - VictoriaMetrics Anomaly Detection product.

This provides seamless integration with vmanomaly REST API and documentation for AI-assisted anomaly detection, model management, and observability insights.

Features

This MCP server enables AI assistants like Claude to interact with vmanomaly for:

• Health Monitoring: Check vmanomaly server health and build information
• Model Management: Discover UI-compatible models and validate univariate or multivariate configurations
• Data-Driven Recommendations: Profile sampled time series and run shared autotune suggestions for one production-ready model config across many returned series
• Configuration Generation: Generate complete vmanomaly YAML configurations
• Alert Rule Generation: Generate vmalert alerting rules based on anomaly score metrics to simplify alerting setup
• Documentation Search: Full-text search across embedded vmanomaly documentation with fuzzy matching

The MCP server contains embedded up-to-date vmanomaly documentation and is able to search it without online access.

The quality of the MCP Server and its responses depends very much on the capabilities of your client and the quality of the model you are using.

Requirements

• vmanomaly instance with REST API access:
  • version 1.28.3+ for the core MCP toolset
  • version 1.30.0+ for time-series characteristics and task-based shared autotune
  • version 1.30.5+ for named-query shared autotune and query-policy suggestions in VMUI
  • version 1.31.0+ for experimental peer-group tuning and deployment sizing
• Go 1.26.10 or higher (if building from source)

Installation

Go

go install github.com/VictoriaMetrics/mcp-vmanomaly/cmd/[email protected]

Replace vX.Y.Z with the exact release you have reviewed.

Binaries

Download the latest release from Releases page and put it to your PATH.

Example for Linux x86_64 (other architectures and platforms are also available). Select an explicit release rather than a mutable latest URL, verify its checksum, and then verify its GitHub build-provenance attestation:

version=vX.Y.Z
archive=mcp-vmanomaly_Linux_x86_64.tar.gz
curl -fLO "https://github.com/VictoriaMetrics/mcp-vmanomaly/releases/download/${version}/${archive}"
curl -fLO "https://github.com/VictoriaMetrics/mcp-vmanomaly/releases/download/${version}/checksums.txt"
grep "  ${archive}$" checksums.txt | sha256sum --check -
gh attestation verify "${archive}" --repo VictoriaMetrics/mcp-vmanomaly
tar axvf "${archive}"
./mcp-vmanomaly --version

Build-provenance attestations are available for releases produced by the hardened release workflow. Release tags must be annotated, cryptographically signed, and marked as verified by GitHub before that workflow publishes artifacts.

Docker

You can run vmanomaly MCP Server using Docker.

This is the easiest way to get started without needing to install Go or build from source.

docker run -d --name mcp-vmanomaly \
  --add-host=host.docker.internal:host-gateway \
  -e VMANOMALY_ENDPOINT=http://host.docker.internal:8490 \
  -e MCP_SERVER_MODE=http \
  -e MCP_LISTEN_ADDR=:8080 \
  -p 127.0.0.1:8080:8080 \
  ghcr.io/victoriametrics/mcp-vmanomaly:vX.Y.Z

Replace vX.Y.Z and the environment variables with your own parameters. When both services run in Docker, prefer a private Docker network and use the vmanomaly service name as the endpoint.

Note that the MCP_SERVER_MODE=http flag is used to enable Streamable HTTP mode. More details about server modes can be found in the Configuration section.

See available docker images in github registry.

Also see Using Docker instead of binary section for more details about using Docker with MCP server with clients in stdio mode.

Source Code

For building binary from source code you can use the following approach:

• Clone repo:

  git clone https://github.com/VictoriaMetrics/mcp-vmanomaly.git
  cd mcp-vmanomaly
  

• Build binary from cloned source code:

  make build
  # after that you can find binary mcp-vmanomaly and copy this file to your PATH or run inplace
  

• Build image from cloned source code:

  docker build -t mcp-vmanomaly .
  # after that you can use docker image mcp-vmanomaly for running or pushing
  

  For local UI/Copilot testing from the vmanomaly repository, build with a local tag:

  docker build -t mcp-vmanomaly:local .
  

  Then run the vmanomaly repository helper with:

  MCP_VMANOMALY_IMAGE=mcp-vmanomaly:local bin/run-mcp-http.sh
  

Configuration

MCP Server for vmanomaly is configured via environment variables:

Variable	Description	Required	Default	Allowed values
VMANOMALY_ENDPOINT	vmanomaly server endpoint URL (e.g., http://localhost:8490)	Yes	-	-
VMANOMALY_BEARER_TOKEN	Bearer token for authenticating with vmanomaly API (mutually exclusive with the token file)	No	-	-
VMANOMALY_BEARER_TOKEN_FILE	Path to a bearer-token file, suitable for mounted container/orchestrator secrets	No	-	-
VMANOMALY_HEADERS	Custom HTTP headers for requests (comma-separated key=value pairs, e.g., X-Custom=value1,X-Auth=value2)	No	-	-
VMANOMALY_REQUEST_TIMEOUT	HTTP timeout for calls from MCP to vmanomaly, e.g. 60s	No	30s	-
MCP_SERVER_MODE	Server operation mode. See Modes for details.	No	stdio	stdio, http, sse
MCP_LISTEN_ADDR	Address for HTTP server to listen on	No	localhost:8080	-
MCP_ENABLED_TOOLS	Positive comma-separated tool allowlist; empty enables all registered tools	No	-	-
MCP_DISABLED_TOOLS	Comma-separated tool denylist; takes precedence over the allowlist	No	-	-
MCP_DISABLE_RESOURCES	Disable all resources (documentation search will continue to work)	No	false	false, true
MCP_HEARTBEAT_INTERVAL	Heartbeat interval for streamable-http protocol (keeps connection alive through network infrastructure)	No	30s	-
MCP_LOG_LEVEL	Log level: debug (verbose), info (default), warn, or error	No	info	-
MCP_LOG_FILE	Log file path (empty = stderr)	No	stderr	-

Modes

MCP Server supports the following modes of operation (transports):

• stdio - Standard input/output mode, where the server reads commands from standard input and writes responses to standard output. This is the default mode and is suitable for local servers.
• http - Streamable HTTP. Server will expose the /mcp endpoint for HTTP connections.
• sse - Server-Sent Events. Server will expose the /sse and /message endpoints for SSE connections.

Note

The sse transport mode was officially deprecated from MCP Specification (version 2025-03-26) and was replaced by Streamable HTTP transport (http mode). In future releases its support can be deprecated, use Streamable HTTP transport if your client supports it.

More info about transports you can find in MCP docs:

• Core concepts → Transports
• Specifications → Transports

Configuration examples

# Basic configuration
export VMANOMALY_ENDPOINT="http://localhost:8490"

# With authentication
export VMANOMALY_ENDPOINT="http://localhost:8490"
export VMANOMALY_BEARER_TOKEN="your-token"

# Or load the token from a mounted secret file
export VMANOMALY_BEARER_TOKEN_FILE="/run/secrets/vmanomaly-token"

# With custom headers (e.g., behind a reverse proxy)
export VMANOMALY_HEADERS="X-Custom-Header=value1,X-Another=value2"

# Expose only the tools required by this deployment. A denylist can further
# narrow this set and always takes precedence.
export MCP_ENABLED_TOOLS="vmanomaly_health_check,vmanomaly_search_docs"
export MCP_DISABLED_TOOLS="vmanomaly_get_metrics"

# Server mode
export MCP_SERVER_MODE="http"
export MCP_LISTEN_ADDR="0.0.0.0:8080"

# Logging
export MCP_LOG_LEVEL="debug"
export MCP_LOG_FILE="/tmp/mcp-vmanomaly.log"

Endpoints

In HTTP and SSE modes the MCP server provides the following endpoints:

Endpoint	Description
/mcp	HTTP endpoint for streaming messages in HTTP mode (for MCP clients that support Streamable HTTP)
/metrics	Metrics in Prometheus format for monitoring the MCP server
/health/liveness	Liveness check endpoint to ensure the server is running
/health/readiness	Readiness check endpoint to ensure the server is ready to accept requests
/sse + /message	Endpoints for messages in SSE mode (for MCP clients that support SSE)

Security

Treat an MCP client as an operator of every enabled tool. The server forwards requests to vmanomaly with the process-wide bearer token and headers configured at startup; it does not add an independent user identity or authorization boundary.

Use one of these routing models while preserving the invariant that each tool call reaches only the caller's trusted-domain vmanomaly installation:

• A local per-user stdio process may use that user's token as its configured upstream token.

• A remote MCP instance dedicated to one trusted domain may use a domain-scoped service token.

• A shared remote MCP requires per-request forwarding of a verified user token so the gateway can route each call to the correct trusted domain. The current process-wide token configuration does not implement this pass-through mode; do not place multiple untrusted domains behind one static MCP credential.

• Prefer stdio for a local, single-user integration. It has no network listener and inherits access control from the process that launches it.

• HTTP and SSE transports do not provide built-in client authentication. Keep the default loopback bind where possible. If remote access is required, place the server behind an authenticated TLS reverse proxy such as vmauth, restrict the network path, and do not expose /mcp, /sse, or /message directly to an untrusted network.

• Keep /metrics on an internal monitoring network or protect it at the proxy; health endpoints can be exposed only as required by the deployment platform.

• Give the configured vmanomaly credential the least privilege and trusted-domain scope available. Prefer VMANOMALY_BEARER_TOKEN_FILE for mounted secrets; never put tokens in command-line arguments, image layers, or committed client configuration.

• Treat VMANOMALY_HEADERS as trusted operator configuration. Tools that set pass_auth_headers=true can ask vmanomaly to forward authorization to a datasource, so permit that only for approved datasource origins and enforce an outbound network policy.

• Use MCP_ENABLED_TOOLS as a deployment allowlist. Both the allowlist and denylist are enforced for discovery and direct invocation, so hidden tools cannot be called by name. An empty allowlist retains backward compatibility by enabling every registered tool.

• MCP_DISABLE_RESOURCES=true hides resource discovery and reads. The documentation-search tool remains independent and can be separately disabled with the tool policy.

• Logs and metrics intentionally omit tool arguments/results, raw errors, client metadata, and resource URIs. Treat MCP responses and downstream vmanomaly logs as sensitive nevertheless.

These controls reduce the MCP server's exposure but do not create tenant isolation. Treat one logical vmanomaly installation, including its replicas or shards, as one trusted domain. Route mutually untrusted domains to separate installations through vmauth or another authenticated gateway. Users inside one trusted domain share its task and resource boundary.

Report suspected vulnerabilities using the private process in SECURITY.md.

Setup in clients

Cursor

Go to: Settings → Cursor Settings → MCP → Add new global MCP server and paste the following configuration into your Cursor ~/.cursor/mcp.json file:

{
  "mcpServers": {
    "vmanomaly": {
      "command": "/path/to/mcp-vmanomaly",
      "env": {
        "VMANOMALY_ENDPOINT": "http://localhost:8490",
        "VMANOMALY_BEARER_TOKEN": "<YOUR_TOKEN>",
        "VMANOMALY_HEADERS": "X-Custom=value1,X-Auth=value2"
      }
    }
  }
}

See Cursor MCP docs for more info.

Claude Desktop

Add this to your Claude Desktop claude_desktop_config.json file (you can find it if open Settings → Developer → Edit config):

{
  "mcpServers": {
    "vmanomaly": {
      "command": "/path/to/mcp-vmanomaly",
      "env": {
        "VMANOMALY_ENDPOINT": "http://localhost:8490",
        "VMANOMALY_BEARER_TOKEN": "<YOUR_TOKEN>",
        "VMANOMALY_HEADERS": "X-Custom=value1,X-Auth=value2"
      }
    }
  }
}

See Claude Desktop MCP docs for more info.

Claude Code

Run the command:

claude mcp add vmanomaly -- /path/to/mcp-vmanomaly \
  -e VMANOMALY_ENDPOINT=http://localhost:8490 \
  -e VMANOMALY_BEARER_TOKEN=<YOUR_TOKEN> \
  -e VMANOMALY_HEADERS="X-Custom=value1,X-Auth=value2"

See Claude Code MCP docs for more info.

Visual Studio Code

Add this to your VS Code MCP config file:

{
  "servers": {
    "vmanomaly": {
      "type": "stdio",
      "command": "/path/to/mcp-vmanomaly",
      "env": {
        "VMANOMALY_ENDPOINT": "http://localhost:8490",
        "VMANOMALY_BEARER_TOKEN": "<YOUR_TOKEN>",
        "VMANOMALY_HEADERS": "X-Custom=value1,X-Auth=value2"
      }
    }
  }
}

See VS Code MCP docs for more info.

Zed

Add the following to your Zed config file:

  "context_servers": {
    "vmanomaly": {
      "command": {
        "path": "/path/to/mcp-vmanomaly",
        "args": [],
        "env": {
          "VMANOMALY_ENDPOINT": "http://localhost:8490",
          "VMANOMALY_BEARER_TOKEN": "<YOUR_TOKEN>",
          "VMANOMALY_HEADERS": "X-Custom=value1,X-Auth=value2"
        }
      },
      "settings": {}
    }
  }

See Zed MCP docs for more info.

JetBrains IDEs

• Open Settings → Tools → AI Assistant → Model Context Protocol (MCP).
• Click Add (+)
• Select As JSON
• Put the following to the input field:

{
  "mcpServers": {
    "vmanomaly": {
      "command": "/path/to/mcp-vmanomaly",
      "env": {
        "VMANOMALY_ENDPOINT": "http://localhost:8490",
        "VMANOMALY_BEARER_TOKEN": "<YOUR_TOKEN>",
        "VMANOMALY_HEADERS": "X-Custom=value1,X-Auth=value2"
      }
    }
  }
}

Windsurf

Add the following to your Windsurf MCP config file:

{
  "mcpServers": {
    "vmanomaly": {
      "command": "/path/to/mcp-vmanomaly",
      "env": {
        "VMANOMALY_ENDPOINT": "http://localhost:8490",
        "VMANOMALY_BEARER_TOKEN": "<YOUR_TOKEN>",
        "VMANOMALY_HEADERS": "X-Custom=value1,X-Auth=value2"
      }
    }
  }
}

See Windsurf MCP docs for more info.

Using Docker instead of binary

You can run vmanomaly MCP server using Docker instead of local binary.

You should replace run command in configuration examples above in the following way:

{
  "mcpServers": {
    "vmanomaly": {
      "command": "docker",
      "args": [
        "run",
        "-i", "--rm",
        "-e", "VMANOMALY_ENDPOINT",
        "-e", "VMANOMALY_BEARER_TOKEN",
        "-e", "VMANOMALY_HEADERS",
        "ghcr.io/victoriametrics/mcp-vmanomaly"
      ],
      "env": {
        "VMANOMALY_ENDPOINT": "http://localhost:8490",
        "VMANOMALY_BEARER_TOKEN": "<YOUR_TOKEN>",
        "VMANOMALY_HEADERS": "X-Custom=value1,X-Auth=value2"
      }
    }
  }
}

Usage

After installing and configuring the MCP server, you can start using it with your favorite MCP client.

You can start dialog with AI assistant from the phrase:

Use MCP vmanomaly in the following answers

But it's not required, you can just start asking questions and the assistant will automatically use the tools and documentation to provide you with the best answers.

Toolset

MCP vmanomaly provides tools organized into categories:

Bounded metric discovery

vmanomaly_discover_metrics calls the additive POST /api/v1/discovery API. It is not part of the vmanomaly 1.31.0 baseline: check the installed endpoint, and treat 404 as unsupported. Supply a datasource, optional explicit tenant, selectors and a fixed window. Tenant scope may be numeric (accountID or accountID:projectID) or explicitly multitenant, including a /select/multitenant/prometheus datasource URL; conflicting URL/request tenants are rejected by the discovery API. Multitenant metadata reads require VictoriaMetrics v1.104.0 or newer and a discovery API version that accepts this scope. Preserve vm_account_id/vm_project_id selectors and returned series labels; never automatically broaden a numeric tenant scope. Metric/label inventories across tenants do not establish per-tenant coverage. Each call performs one metadata request; no historical samples, retries or tenant enumeration. Defaults are 100 results and 10 seconds; maxima are 1,000 results, 10 selectors, 31 days and 30 seconds. The MCP client caps response bytes but does not limit concurrent discovery calls; server-side admission limits depend on the deployed backend. These caps do not bound the TSDB index scan. Preserve upstream warnings and completeness; returned counts are neither total cardinality nor exact historical coverage.

Preset configuration and alert artifacts

vmanomaly_generate_preset_artifacts calls the additive POST /api/v1/preset/artifacts API. It is not part of the vmanomaly 1.31.0 baseline: check endpoint support and treat 404 as unsupported. Supply a complete configuration with explicit reader and VictoriaMetrics writer destinations, models and schedulers. Optional alert policy controls threshold, evaluation interval, persistence and the externally reachable incident base URL. entity_labels contains only known source labels; omit it for query-group links. Results retain structured configuration/rules, equivalent YAML, schema version and warnings. The request is limited to 1 MiB and the response to 8 MiB.

Generation is read-only. schema-valid does not establish data coverage, sizing, connectivity, alert delivery or deployment readiness. The existing configuration and example-rule tools remain available; a successful validation response describes schema validation only. Use separate rendering and live checks before deployment.

Health & Info (4 tools)

Tool	Description
vmanomaly_health_check	Check vmanomaly server health status
vmanomaly_get_buildinfo	Get build information (version, build time, Go version)
vmanomaly_get_server_queries	Get configured server query aliases and expressions
vmanomaly_get_metrics	Get vmanomaly server metrics in Prometheus format

Deployment sizing (3 tools)

Peer-pool sizing is experimental and requires backend support: use model_class: peer_outlier, options.topology: wide and options.channels_per_entity for peers per pool. Forward entity_count counts pools; reverse capacity counts pool-models, with peer-series count returned separately. For example, two five-peer pools are two entities and ten input series. Initial support is limited to equal-size fixed pools (3–10,000 peers, meeting min_peer_count, default 5), complete observations, one query per workload and no churn retention. Omit model_params.groupby; declare separate forward workloads for distinct queries or pool sizes. Do not average unequal pools or replace an unsupported peer estimate with univariate sizing. No peer profile is initially shipped; bounded live calibration requires the installed backend version. Pool widths above 64 use bounded-sample n log(n) CPU and linear memory/output approximations. Shared fallback worker coefficients are not peer-specific measurements. Keep the user's requested pool width; never substitute a smaller pool. Estimates need representative validation.

Currently experimental as of vmanomaly v1.31.0; requires a server exposing the deployment-sizing API. Earlier targets are unsupported; an omitted target uses the installed server version. Report any version fallback returned by the server without claiming validation on the requested release. Deployment sizing estimates resources for vmanomaly itself, rather than forecasting a monitored metric with forecast_at.

Tool	Purpose
vmanomaly_estimate_deployment_resources	Deployment CPU/RAM/disk and composable stage estimates
vmanomaly_estimate_inference_capacity	Approximate active models per inference interval at fixed CPUs, optionally RAM constrained
vmanomaly_get_deployment_sizing_profiles	Discover supported sizing profiles and their model parameters

Forward sizing accepts workloads, each with model_class, entity_count and infer_every_seconds. Reverse sizing needs model_class, cpus and infer_every_seconds; ram_limit_bytes is optional. Each accepts an options object for the corresponding backend fields, with workload-specific options nested in each workload. For example:

{"model_class":"mad_online","cpus":2,"infer_every_seconds":300,"ram_limit_bytes":2147483648,"options":{"vmanomaly_version":"v1.31.0","infer_points_per_cycle":2}}

Choose the flow by the unknown: a known series count needs forward sizing; fixed CPU/RAM and cadence with no count needs reverse sizing, even if the user simply asks for "capacity". Do not request cardinality for reverse sizing. The output is active model/entity count: univariate entities are series, multivariate entities are groups. Supply topology and channels_per_entity for multivariate requests and report input_series separately. Missing history can be clarified or explicitly defaulted. Compare memory and disk with otherwise identical inputs. In reverse sizing, an explicit numeric history.step_seconds defaults the scored batch to ceil(infer_every_seconds / step_seconds) unless infer_points_per_cycle is supplied. MCP reports this non-overlapping-cycle assumption alongside successful and failed sizing results.

For online models, forward sizing automatically treats fit duration as advisory against inference cadence; fit peak RAM/disk still count. Provide history window/step and omit fit_every_seconds unless the user requests periodic refits. Never infer refit cadence from fit_window. mad/mad_online and zscore/zscore_online resolve to the same online classes. An explicit finite interval includes recurring compute. Batch models keep hard fit deadlines and default to daily fitting. Use explicit options.deployment.members_count and split_by=queries for a fixed query-shard layout.

Results preserve resolved inputs, stage costs, resource constraints and operational warnings, with a single experimental-estimate notice. Internal calibration diagnostics are omitted from forward/reverse tool results; profile discovery is returned unchanged. Reverse sizing covers inference only, excluding bootstrap/refits/churn. Check the model schema or profile before supplying required parameters; do not invent them. Unsupported seasonal configurations require a matching profile or offline calibration, rather than fewer series or a different cadence.

Requests use the existing authenticated backend client, fixed routes, bounded request bodies and a bounded cancelable queue. The request timeout includes waiting, and profile discovery remains independent. Backend validation and overload errors are returned as tool errors without automatic retries; the session can accept a corrected follow-up. Older servers may not expose these routes. These tools do not change a running deployment.

Forward sizing resolves omitted scored points from explicit sampling and cadence, and defaults the inference deadline to the shortest workload cadence. Explicit overrides are preserved. An infeasible explicit deployment returns binding constraints; the adapter does not retry or substitute a balanced repartition. Compare CPU candidates in one call, and keep nominal versus margin-adjusted times distinct.

Model Configuration (4 tools)

Tool	Description
vmanomaly_list_models	List models exposed to VMUI and other UI-oriented flows
vmanomaly_get_server_models	Get configured server models and their query attachments
vmanomaly_get_model_schema	Get JSON schema for a specific model type
vmanomaly_validate_model_config	Validate model configuration before using it

Configuration (1 tool)

Tool	Description
vmanomaly_validate_config	Validate complete vmanomaly YAML configuration

Documentation (1 tool)

Tool	Description
vmanomaly_search_docs	Full-text search across vmanomaly documentation with fuzzy matching

Compatibility (1 tool)

Tool	Description
vmanomaly_check_compatibility	Check if persisted state is compatible with runtime version

Alerting (1 tool)

Tool	Description
vmanomaly_generate_alert_rule	Generate VMAlert rule YAML for anomaly score alerting

Analysis & Autotune (4 tools)

Tool	Description
vmanomaly_timeseries_characteristics	Profile sampled query results for trends, seasonalities, spikiness, and gaps
vmanomaly_create_autotune_task	Start tuning one requested model class on sampled series
vmanomaly_get_autotune_task	Poll autotune progress and retrieve a completed recommendation
vmanomaly_cancel_autotune_task	Request cooperative cancellation of an autotune task

vmanomaly_create_autotune_task accepts optimization_n_trials, optimization_timeout, and advanced optimization_params to bound Optuna work. The MCP tool uses interactive defaults of 32 trials and 8 seconds when no optimization budget is provided, and a conservative anomaly fraction of 0.02 when anomaly_percentage is omitted; the vmanomaly API defaults are larger. Poll vmanomaly_get_autotune_task until status is done, then use the recommendation under result_data. Treat error and canceled as terminal statuses.

The running server's list/schema endpoints expose UI-compatible models, not an exhaustive catalog of every deployable model. Their contents depend on the server version; servers supporting the corresponding investigation views can include multivariate and peer-group models. Check the returned list and schema rather than assuming those models are always present or always excluded.

For multivariate detection, tune the multivariate class directly with aligned named queries and any frozen_params.groupby labels; the result uses a joint anomaly score. Documented models not exposed by an older server's UI endpoints may still support server-side tuning and complete configuration validation; verify that server's capabilities before using them or suggesting them in VMUI.

With vmanomaly 1.31.0+, shared tuning accepts peer_outlier. Keep entity labels in query results and supply population grouping in frozen_params.groupby; queries remain separate populations. Stable query policies remain authoritative. The tuning result is a concrete model configuration: deployment sizing can estimate that model's fit/inference resources, not the auto wrapper's search cost. Supervised marking is available in VMUI; the current MCP tuning tool exposes the unsupervised objective, not label submission.

For new configurations, prefer online models. Prophet, Holt-Winters, and Isolation Forest remain supported for existing deployments but are planned for future deprecation; use Temporal Envelope as the corresponding univariate or multivariate migration target.

Dialog example

This example shows data-driven model selection rather than choosing a model from the metric name. The YAML is a complete deployment-config excerpt: VMUI suggestion cards continue to carry business-policy fields in the model configuration because the UI query editor currently exposes only the query expression and language.

• You: Detect sustained CPU spikes for avg by (instance) (1 - rate(node_cpu_seconds_total{mode="idle"}[5m])) at a 5m step.

• Assistant: I profiled the exact query first. The sampled series contain a trend and recurring hour-of-day/day-of-week structure, so temporal_envelope is the best online starting point. If the profile had no meaningful trend or seasonality, I would prefer mad_online for robust data, or zscore_online only for a stable light-tailed distribution.

• Assistant: I verified the model and schema, then started shared autotune with the same 5m step, anomaly_percentage=0.02, and causal exact=true validation. After sequentially polling the task to completion, I validated the returned model configuration before presenting it.

  reader:
    workers: 0
    queries:
      cpu_non_idle:
        expr: avg by (instance) (1 - rate(node_cpu_seconds_total{mode="idle"}[5m]))
        detection_direction: above_expected
        min_rel_dev_from_expected: [0, 15]
  
  models:
    cpu_envelope:
      class: temporal_envelope
      queries: [cpu_non_idle]
      schedulers: [cpu_5m]
      seasonalities: [hod_smooth, dow_smooth]
  

  The exact tuned parameters depend on the sampled data; the final model spec is always validated against the running vmanomaly instance.

During this dialog, the assistant used the following tools:

• vmanomaly_timeseries_characteristics to measure the sampled data profile
• vmanomaly_list_models and vmanomaly_get_model_schema to verify the UI-compatible model
• vmanomaly_create_autotune_task and vmanomaly_get_autotune_task to tune shared parameters
• vmanomaly_validate_model_config to validate the tuned model
• vmanomaly_validate_config to validate the configuration

Monitoring

In HTTP and SSE modes the MCP Server provides metrics in Prometheus format at the /metrics endpoint.

Tracked operations:

• mcp_vmanomaly_initialize_total - Client connections
• mcp_vmanomaly_call_tool_total{name,is_error} - Tool calls with success/error tracking
• mcp_vmanomaly_read_resource_total - Documentation resource reads
• mcp_vmanomaly_list_*_total - List operations (tools, resources, prompts)
• mcp_vmanomaly_error_total{method,error_class} - Errors by bounded, non-sensitive class

Example:

# Start in HTTP mode
VMANOMALY_ENDPOINT="http://localhost:8490" MCP_SERVER_MODE=http ./bin/mcp-vmanomaly

# Query metrics
curl http://localhost:8080/metrics

Roadmap

• Grafana dashboard for MCP server monitoring
• Add API compatibility matrix to gracefully handle version differences between MCP client and vmanomaly server (API is evolving, features may be unavailable)

Disclaimer

AI services and agents along with MCP servers like this cannot guarantee the accuracy, completeness and reliability of results. You should double check the results obtained with AI.

The quality of the MCP Server and its responses depends very much on the capabilities of your client and the quality of the model you are using.

Contributing

Contributions to the MCP vmanomaly project are welcome!

Please feel free to submit issues, feature requests, or pull requests.

Related Projects

• vmanomaly - VictoriaMetrics anomaly detection
• VictoriaMetrics - Time series database
• mcp-victoriametrics - MCP server for VictoriaMetrics
• Model Context Protocol - MCP specification

Support

For vmanomaly-specific questions, see the vmanomaly documentation.

For MCP server issues, please open an issue in this repository.