Most PromQL written from memory fails on the name or the unit rather than the logic, and the catalogue and metadata calls put both in front of you before the query runs. The targets call is the other half: when a series is missing, it distinguishes a metric that was never exported from a target that stopped being scraped.
A read path onto a Prometheus server: instant and range queries, the metric catalogue, metric metadata and scrape targets. Nothing here writes rules, silences or configuration.
- Instant PromQL queries at an optional point in time
- Range queries taking start, end and a step interval, so a window of history comes back in one call
- Metric discovery with a filter pattern and paging, for a catalogue too large to read at once
- Metadata per metric — type, help text and unit — searchable by pattern across both names and descriptions
- Scrape targets filtered by state and scrape pool, which is where a missing series usually turns out to be explained
- A health check for container monitoring
- Prometheus UI links attached to query results, and a switch to leave them off when they are costing more context than they are worth
- Two instances side by side: TOOL_PREFIX renames the tools, so a staging server and a production one do not collide in the same client
A reachable Prometheus server and its address in PROMETHEUS_URL. Run it from the published container image, a Helm chart on Kubernetes, or locally with uv. Authentication covers what Prometheus deployments actually use: basic auth through PROMETHEUS_USERNAME and PROMETHEUS_PASSWORD, a bearer token in PROMETHEUS_TOKEN, or mutual TLS with a client certificate and key. ORG_ID handles a multi-tenant setup, and PROMETHEUS_CUSTOM_HEADERS covers a proxy that wants its own headers. stdio by default, with HTTP or SSE and a stateless mode for running several replicas. MIT.
One command — claude mcp add prometheus --env PROMETHEUS_URL=http://your-prometheus:9090 -- docker run -i --rm -e PROMETHEUS_URL ghcr.io/pab1it0/prometheus-mcp-server:latest