MCP Server

Most monitoring and observability work still happens through a UI a human drives. MCP MCP server moves it into the conversation instead. MCP Server for vmanomaly - VictoriaMetrics anomaly detection.

The short version

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

• 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 tools it exposes

The server publishes 14 tools. What each one is for:

• 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
• 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
• 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

What it needs from you

Configuration is passed through the environment: VMANOMALY_ENDPOINT, VMANOMALY_BEARER_TOKEN, VMANOMALY_HEADERS, MCP_SERVER_MODE, MCP_LISTEN_ADDR, MCP_LOG_LEVEL, MCP_LOG_FILE, YOUR_TOKEN. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.

• 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 - Go 1.24 or higher (if building

Getting it running

Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client.

How it compares

Plenty of monitoring and observability servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. MCP's toolset — vmanomaly_health_check, vmanomaly_get_buildinfo, vmanomaly_get_server_queries and 11 more — is a fair guide to whether it matches your workflow. It is maintained by VictoriaMetrics-Community; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.

Things to watch

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• With 14 tools registered it takes up a noticeable share of the context window; turn it off in projects that never touch MCP.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• Keep per-call confirmation enabled while you learn its behaviour; it is the cheapest safeguard you have.