Prometheus MCP Server

Prometheus MCP Server

About

This is an MCP server to allow LLMs to interact with a running Prometheus instance via the API to do things like generate and execute promql queries, list and analyze metrics, etc.

Demos and Examples

Asking Claude to Investigate Slow Queries

The prompt used was:

querying my metrics is slow, can you help me figure out why?

Investigate metrics produced by the MCP server itself and suggest recording rules for SLOs

The prompt used was:

use the tools from the prometheus mcp server to investigate the metrics from

the mcp server and suggest prometheus recording rules for SLOs

Summarize Prometheus metric/label naming best practices

The prompt used was:

summarize prometheus metric/label name best practices

Report on the health of the Prometheus instance that powers prometheus.demo.prometheus.io

The prompt used was:

please provide a comprehensive review and summary of the prometheus server.

review it's configuration, flags, runtime/build info, and anything else that

you feel may provide insight into the status of the prometheus instance,

including analyzing metrics and executing queries

Tools

The Prometheus HTTP API outputs JSON data, and the tools in this MCP server return that JSON to the LLM for processing as it's structured and well understood by LLMs.

LLMs and Token/Context Efficiency

This MCP server supports the following options which have the potential to reduce token/context usage:

TOON Encoding

If token/context usage is a concern, this MCP server also supports converting the API's JSON data to the Token-Oriented Object Notation (TOON) format. While it is not guaranteed to reduce token usage, it is designed with token efficiency in mind. As noted on TOON's documentation, it excels at uniform arrays of objects; non-uniform/complex objects may still be more token-efficient in JSON. Real world token usage will depend on usage patterns, please review common workflows to determine if TOON output may be beneficial. Please see Flags for more information on the available flags and their corresponding environment variables.

API Response Truncation

This feature allows you to set a maximum limit on the number of lines or entries returned from the Prometheus API for, which can help in reducing the amount of data sent to the LLM. Setting the limit to 0 disables truncation. Truncation is disabled by default. Note that LLMs capable of handling tool request arguments can override this global truncation limit on a per-tool-call basis for supported tools. Please see Flags for more information on the available flags and their corresponding environment variables.

Full Tool List

NOTE:

Because the TSDB Admin API endpoints

allow for potentially destructive operations like deleting data, they are not

enabled by default. In order to enable the TSDB Admin API endpoints, the MCP

server must be started with the flag --dangerous.enable-tsdb-admin-tools to

acknowledge the associated risk these endpoints carry.

Tool Sets

The server exposes many tools to interact with Prometheus. There are tools to interact with Prometheus via the API, as well as additional tools to do things like read documentation, etc. By default, they are all registered and available for use (TSDB Admin API tools need an extra flag).

To be considerate to LLMs with smaller context windows, it's possible to pass in a whitelist of specific tools to register with the server. The following 'core' tools are always loaded: [docs_list, docs_read, docs_search, runbooks_list, runbooks_read, query, range_query, metric_metadata, label_names, label_values, series]. Additional tools can be specified with the --mcp.tools flag.

For example, the command line:

prometheus-mcp --mcp.tools=build_info --mcp.tools=flags --mcp.tools=runtime_info

Would result in the following tools being loaded:

• build_info
• docs_list
• docs_read
• docs_search
• flags
• label_names
• label_values
• metric_metadata
• query
• range_query
• runbooks_list
• runbooks_read
• runtime_info
• series

Runbooks (Agent Skills) and Prompts

The server embeds a set of runbooks: guided workflows for common Prometheus tasks, expressed in terms of the server's tools. Each runbook orients the model on the relevant tools, then suggests topics to explore with example queries rather than prescribing a fixed sequence of steps. Runbooks cover tasks like system health checks, missing-data triage, error-rate investigation, high-cardinality optimization, recording/alerting rule review, and configuration/performance tuning.

Each runbook is packaged as a full Agent Skill: a directory containing a SKILL.md with name/description frontmatter. Runbooks are exposed three ways:

• Tools: the model can discover and read them itself via the runbooks_list/runbooks_read tools when a request matches a runbook's purpose. Tools are the most portable path and work in every MCP client.
• Skill resources: per the SEP-2640 skills extension draft, each runbook is a skill:// /SKILL.md resource, enumerated by the well-known skill://index.json discovery index, and the server declares the io.modelcontextprotocol/skills extension capability. Skill-aware hosts can consume these like local filesystem skills; other clients can still read them as ordinary MCP resources.
• MCP prompts: each runbook is also registered as an MCP prompt under its skill name (e.g. check-system-health, optimize-high-cardinality), so clients with prompt support can invoke a guided workflow directly (often surfaced as slash commands).

Prometheus Compatible Backends

There are many Prometheus compatible backends that can be used to extend prometheus in a variety of ways, often with the goals of offering long term storage or query aggregation from multiple prometheus instances. Some examples can be found in the Remote Storage of prometheus' docs.

Many of those services also offer a "prometheus compatible" API that can be used to query/interact with the data using native promQL. In general, this MCP server should at a minimum work for other prometheus API compatible services to execute queries and interact with the series/labels/metadata endpoints for metric and label discovery. Beyond that, there may be API differences as the different systems implement different parts/extensions of the API for their needs.

Examples:

• Thanos does not use a centralized config, so the config endpoint is not implemented and thus the config tool is removed.
• Mimir and Cortex implement extra endpoints to manage/add/remove rules

To workaround this and provide a better experience on some of the commonly used Prometheus compatible systems, this project may add direct support for select systems to provide different/more tools. Choosing a specific prometheus backend implementation can be done with the --prometheus.backend flag. The list of available backend implementations on a given release of the MCP server can be found in the output of the --help flag. Qualifications and support criteria are still under consideration, please open an issue to request support/features for a specific backend for further discussion.

Prometheus Backend Implementation Differences

| Backend |