Prometheus MCP Server
About
A Prometheus MCP server with full API support for comprehensive management and deep interaction with Prometheus beyond basic query support. Written in go, it is a single binary install that is capable of STDIO, SSE, and HTTP transports for complex deployments.
Details
- Author
- tjhop
- Categories
- Database, Infrastructure, Other
Jump to
Setup
Install Prometheus MCP Server in your MCP client (Claude Desktop, Cursor, Windsurf, and others).
Repository: https://github.com/tjhop/prometheus-mcp-server
Follow the installation instructions in the repository README, then restart your MCP client.
This is anMCPserver to allow LLMs to interact with a runningPrometheusinstance via the API to do things like generate and execute promql queries, list and analyze metrics, etc.
Asking Claude to Investigate Slow Queries
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
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
summarize prometheus metric/label name best practices
Report on the health of the Prometheus instance that powers prometheus.demo.prometheus.io
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
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.
This MCP server supports the following options which have the potential to reduce token/context usage:
If token/context usage is a concern, this MCP server also supports converting the API's JSON data to theToken-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 seeFlagsfor more information on the available flags and their corresponding environment variables.
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 to0disables 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 seeFlagsfor more information on the available flags and their corresponding environment variables.
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.toolsflag.
prometheus-mcp-server --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
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 fullAgent Skill: a directory containing aSKILL.mdwithname/descriptionfrontmatter. Runbooks are exposed three ways:
- Tools: the model can discover and read them itself via therunbooks_list/runbooks_readtools when a request matches a runbook's purpose. Tools are the most portable path and work in every MCP client.
- Skill resources: per theSEP-2640 skills extension draft, each runbook is askill://<name>/SKILL.mdresource, enumerated by the well-knownskill://index.jsondiscovery index, and the server declares theio.modelcontextprotocol/skillsextension 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 anMCP promptunder 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).
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 theRemote Storageof 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.
- Thanos does not use a centralized config, so the config endpoint is not implemented and thus the config tool fails.
- 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.backendflag. The list of available backend implementations on a given release of the MCP server can be found in the output of the[--helpflag. Qualifications and support criteria are still under consideration, please open an issue to request support/features for a specific backend for further discussion.
This MCP server is most useful when fully integrated with tooling and/or installed as a tool server with another system. Installation procedures and integration support will vary depending on the tools being used. For example:
- some systems can only interact with MCP tools and not resources/prompts
- some systems use mcp.json config file format to manage MCP servers and some require custom formats
- some systems don't speak MCP directly and require tools like mcp-to-openapi to proxy
Please check the documentation for the tool being used/integrated for specific instructions and level of support.
…
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
