proposal: adopt MCP server into prometheus org#81
Conversation
Signed-off-by: TJ Hoplock <t.hoplock@gmail.com>
Signed-off-by: TJ Hoplock <t.hoplock@gmail.com>
roidelapluie
left a comment
roidelapluie
left a comment
There was a problem hiding this comment.
LGTM, We can have rules support as a feature flag.
| * **Configurable tool registration:** a small "core" toolset is always loaded; everything else can be allow-listed via `--mcp.tools`, so operators can tune what gets exposed to smaller-context LLMs. | ||
| * **Transports:** stdio, SSE, and streamable HTTP. | ||
| * **HTTP client configuration:** standard Prometheus HTTP config file, including bearer tokens, basic auth, mTLS, custom headers, etc. — i.e. it works with multi-tenant setups (Mimir/Cortex/GrafanaCloud) and TLS-protected Prometheus servers without bespoke flags. | ||
| * **Backend awareness:** `--prometheus.backend` selects per-backend behavior. Today that means a `thanos` backend that hides endpoints Thanos doesn't implement and adds a `list_stores` tool. The same mechanism is the path forward for Mimir/Cortex support. |
There was a problem hiding this comment.
What's the plan of supporting projects in the ecosystem... I imagine there will be nuances among those projects even for common tools.
There was a problem hiding this comment.
Why would that be different from supporting multiple service discoveries in prometheus?
There was a problem hiding this comment.
@yeya24 agreed, and tools are currently registered from a map, which allows for easy overriding. For instance, the thanos toolset right now just takes the tools from the prometheus toolset, skips the ones thanos doesn't support, and adds the list_stores tool:
https://github.com/tjhop/prometheus-mcp-server/blob/main/pkg/mcp/registration.go#L251-L266
And we hold onto the http.RoundTripper that is used to create the prometheus API client and provide wrapper functions so that implementations of custom endpoints are automatically instrumented with metrics + logging, etc.
Similar patterns can be used to override endpoints to pair a tool name with a backend-specific implementation. Cortex/Mimir support are on my radar as well, but they have a much larger API surface.
@roidelapluie functionality wise, I don't think it would be dramatically different. IMO, the bigger difference would be in operating patterns and the precedents that would set. Service discovery provides periodic updates from an external service in a read-only form, whereas adding this type of "backend" like service to Prometheus would move it closer to a proxy type solution. This is especially relevant when talking about supporting services like cortex/mimir which have endpoints to manage rules, and opens the pathway for Prometheus to be effecting change in other systems. Something that I think deserves a lot of weight if/when we consider integrating directly into Prometheus.
|
This is on my radar, looks positive, but I need to dive into details |
4 participants
No description provided.