-
Notifications
You must be signed in to change notification settings - Fork 21
Description
Hey all, opening this issue after suggestion on slack here:
https://cloud-native.slack.com/archives/C167KFM6C/p1752357539419599
Prometheus MCP Servers and Guidance Integrating Prometheus With LLMs
A google search can quickly find several MCP servers for Prometheus (including my own), but currently there is no "official" MCP server for LLMs to interact with Prometheus. It seems like it may be helpful for users if the Prometheus community could consolidate and choose a specific MCP server to either endorse or potentially adopt into the prometheus-community org and directly maintained by the community.
Proposed Options:
- adopt my prometheus MCP server
- Pros:
- Prometheus API complete
- Wide support for Prometheus HTTP client configuration via upstream HTTP config files
- Support for multiple MCP transport modes: stdio, SSE, and bidirectional HTTP
- Native instrumentation to expose prometheus metrics/structured logs
- Written in Go, which is often favored amongst the Prometheus community, and uses first party libraries everywhere possible -- client_golang for API and metrics, common for structured logging and config file loading, exporter-toolkit for flags and the like.
- I regularly contribute to a lot of prometheus stuff already and will commit to maintaining the project
- Cons:
- Imposes yet more maintenance burden, when the prometheus community is already lacking maintainers for some stuff
- Lacking proper go tests (hey, it's my side project right now and I'm actively working on it)
- Pros:
- adopt what is arguably the current most popular prometheus MCP server
- Pros:
- Written in python, very simple and straightforward project
- Support for basic HTTP auth options like basic/token auth
- Cons:
- Not Prometheus API complete
- Limited HTTP client config options
- Pros:
- refer users to something like grafana MCP server
- Pros:
- Already done and actively maintained, has corporate backing
- Has basic prometheus query/metadata call support
- Cons:
- Not Prometheus API complete
- Not necessarily aligned with Prometheus project itself
- Require grafana to be deployed as well, as it queries Prometheus datasources via grafana
- Pros:
As mentioned above, there are also many other options for existing projects that we could consider adopting, but all that I've explored had lesser support (part of why I created my own). Another option of course is to create a new one from scratch, but that seems unnecessary now, at least until existing options have been evaluated.
Is this something that existing prometheus maintainers/community members would be interested in?