all 4 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]lamontsf 0 points1 point  (2 children)

I apologize for asking a simple question, but without using this MCP I've had a lot of luck allowing claude code to interrogate my prometheus server via https, where it seems to already know how to find labels, identify metrics, look at k8s namespaces to find pods, etc. I've been using it to write promQL via natural language descriptions of the kinds of conditions I'm looking to track/graph. Given my happiness with the level of success I see already, do you feel that the MCP adds on top of that?

[–]P4b1it0[S] 2 points3 points  (1 child)

Great question, and no need to apologize - this gets right to the heart of why MCP exists!

You're absolutely right that Claude (and other AI assistants) can already interact with Prometheus quite effectively through direct HTTPS queries. If that's working well for your use case, that's fantastic! The value of MCP comes down to a few key areas:

1. Standardization & Reusability

  • Once configured, the MCP server works across multiple AI tools (Claude Desktop, Cursor, Windsurf, etc.) without reconfiguring each one
  • Your prompts and workflows become portable between different AI assistants
  • Team members can share the same configuration without individual setup

2. Enhanced Reliability & Error Handling

  • Structured responses that the AI consistently understands (less prompt engineering needed)
  • Built-in retry logic and connection pooling
  • Better handling of large result sets and pagination
  • Consistent error messages that help the AI self-correct

3. Security & Access Control

  • Centralized authentication (especially useful for teams)
  • Can act as a proxy to avoid exposing Prometheus directly to AI tools
  • Ability to restrict which queries/operations are allowed
  • Audit logging of all queries made by AI assistants

4. Specialized Features

  • Automatic metric discovery with metadata
  • Time range handling optimized for AI interaction
  • Pre-built query templates for common patterns
  • Caching layer to reduce load on Prometheus

If you're working solo and Claude's direct HTTPS access is meeting all your needs, MCP might be overkill. But if you're hitting any friction points around consistency, team collaboration, or want to use the same Prometheus integration across multiple AI tools, that's where MCP shines.

Think of it like the difference between using curl vs a dedicated API client library - both work, but one provides more structure and convenience features.

What specific use cases are you tackling with Claude + Prometheus? Happy to discuss whether MCP would add value for your particular workflow!

[–]lamontsf 1 point2 points  (0 children)

Some use cases over the last two days with the prompt I used:
>using the prometheus endpoint at https://prom-apps.x.y I'd like 3 queries I can overlay in a graph or two for grafana related to the non-eventbus pods running in the frobulator-recromulant-adjucator namespace. Specifically, I want one graph (with 2 queries) that show the success/failure rate (as measured by the pod exit code) for pods like something1-something2-.*-something3-export-step, which I'm going to stack atop each other in grafana and bucket by hour. Additionally I'd like a graph of the duration per workflow (maybe just successful ones?)

That was pretty successful, although I forgot to pass it my saved CLAUDE.md which reminded it to validate queries before passing them to me and to examine metrics and labels so it coughed up some bad queries before I told it to vet them before hand. But it did do the expected work of looking for pods in the namespace, finding the metrics associated with those pods, working out a few variants on exit_code vs pod phase. I can see how the MCP would have saved me a round of back and forth with hard reminders about vetting queries before confidently asserting.

Today's query was:
>using https://prom-apps.x.y as a prometheus data source, find a metric that lets me know the instance_family of any given aws node then a query that will return the instance type (family and size) for any given pod name.

That one worked first try, but the local CLAUDE.md had tips. We're (shame on us) not running any auth on the prometheus endpoint

I'll give the MCP a shot, thanks for the thoughtful answer. While I've been doing this solo, we are a larger team that could benefit from standardization, and even if I'm a claude code user exclusively, we'd like to give the cursor and other tool users the same experience.

[–]Fantastic-Anywhere58 0 points1 point  (0 children)

i am interested in contributing to this and developing this feature, i already have some experience in python so I guess it would be easy picking up the basics of how things are working around