Prometheus Mcp Server Free

Prometheus 2.50.1 PromQL remote_write MCP MIT

A Prometheus-compatible metrics store on freebase.cloud that you can point an AI assistant at, so "why did p99 latency double on Tuesday afternoon" becomes a query the assistant runs rather than a dashboard you go and stare at.

What this is, and what it isn't

It is	It isn't
A metrics store with the full PromQL engine, reachable over MCP	A replacement for your production monitoring stack
A remote_write target for an existing Prometheus, Grafana Agent or Alloy	An Alertmanager — nothing here pages anybody
A place to prototype SLO expressions against real data	A log store; Prometheus has never been one
Free, without a card, for development-scale volumes	A tier with an SLA, retention promise or support contract
Queryable in natural language once an assistant is connected	A magic layer that removes the need to understand rate()

If you already run Prometheus and want an assistant to answer questions about the metrics, the smallest useful setup is: add a remote_write block pointing here, connect your MCP client, done. If you have no Prometheus at all, you can push exposition-format metrics directly and skip the scraper entirely.

The questions this makes answerable

The worked example throughout is a thumbnail-rendering API: an HTTP front end, a job queue, and a pool of workers that resize images. Six metrics, and the sort of thing an assistant can actually be asked about:

What someone asks	What the assistant needs to run
"Are we serving errors right now?"	sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
"How slow is the slow tail?"	histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
"Is the queue draining or growing?"	deriv(render_queue_depth[15m])
"Which endpoint got worse since yesterday?"	topk(5, sum by (route) (rate(http_requests_total[10m])) - sum by (route) (rate(http_requests_total[10m] offset 1d)))
"Are workers saturated?"	avg by (pool) (render_workers_busy / render_workers_total)
"How much error budget is left this month?"	1 - (sum(increase(http_requests_total{status=~"5.."}[30d])) / sum(increase(http_requests_total[30d]))) / 0.001

Every one of those is in examples/queries.promql, annotated, and runs unchanged against a free Prometheus instance. The point of the table is that the translation from question to PromQL is mechanical once you know the vocabulary — which is exactly the kind of thing a language model is good at, provided the metric names and label sets are discoverable. Making them discoverable is most of the work, and it is covered below.

Getting metrics in

Three routes, in descending order of how likely you are to use them.

1. remote_write from an existing Prometheus. Add to prometheus.yml — endpoint URL and bearer token come from your freebase.cloud dashboard:

remote_write:
  - url: "https://YOUR_INSTANCE/api/v1/write"
    bearer_token: "YOUR_TOKEN"
    write_relabel_configs:
      # Ship the metrics you will actually query. Everything else is noise you
      # pay for in cardinality.
      - source_labels: [__name__]
        regex: "(http_requests_total|http_request_duration_seconds_.*|render_.*)"
        action: keep
    queue_config:
      max_samples_per_send: 2000
      capacity: 10000

That write_relabel_configs block is not optional advice. A default kube-prometheus-stack scrapes tens of thousands of series; forwarding all of it to a development-tier store is how you find the limits within an hour.

2. Grafana Agent or Alloy. A prometheus.remote_write component with the same URL and bearer token. Useful when you want the shipping without running a full Prometheus.

3. Direct exposition format. Push the standard text format over the MCP store tool — a counter, a gauge and a histogram look like this:

# HELP http_requests_total Total HTTP requests handled.
# TYPE http_requests_total counter
http_requests_total{route="/render",status="200",instance="api-1"} 184203
# HELP render_queue_depth Jobs waiting for a worker.
# TYPE render_queue_depth gauge
render_queue_depth{pool="cpu"} 41
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{route="/render",le="0.1"} 12043
http_request_duration_seconds_bucket{route="/render",le="0.5"} 17888
http_request_duration_seconds_bucket{route="/render",le="+Inf"} 18120
http_request_duration_seconds_sum{route="/render"} 4102.7
http_request_duration_seconds_count{route="/render"} 18120

examples/push_synthetic.sh generates a few hours of this shape so the queries have something to chew on before you wire up anything real.

PromQL you should be able to read

Counters only ever go up, so you never query them directly. http_requests_total is a number that has been climbing since the process started; its value tells you almost nothing. rate() turns it into per-second change over a window, handles counter resets when a pod restarts, and is the function you will use more than all the others combined.

rate(http_requests_total{route="/render"}[5m])

The window in brackets must span at least four scrape intervals or the result gets noisy and occasionally empty. At a 15-second scrape interval, [1m] is the floor and [5m] is the sensible default.

rate() on a gauge is meaningless. render_queue_depth goes up and down; rate's counter-reset handling will treat every decrease as a restart and produce nonsense. For gauges you want deriv() (linear regression over the window), delta(), or avg_over_time() / max_over_time(). This is the single most common PromQL mistake, and a model that has been told the metric type will avoid it.

increase() is rate() × window, and is what you want for "how many in the last hour". It is still an extrapolation, so a result of 41.3 requests is normal and not a bug.

Histograms are cumulative buckets. _bucket{le="0.5"} counts every observation at or below 0.5 seconds, not the ones between 0.1 and 0.5. histogram_quantile() interpolates across them:

histogram_quantile(0.99,
  sum by (le, route) (rate(http_request_duration_seconds_bucket[5m]))
)

sum by (le, ...) before histogram_quantile is mandatory — aggregate first, quantile second. Reversing them produces a plausible-looking number that is simply wrong, which is worse than an error. And the accuracy is bounded by your bucket boundaries: if the highest finite bucket is le="1" and your p99 is 3 seconds, the answer will be 1, confidently.

Aggregation drops labels unless you keep them. sum(rate(x[5m])) collapses everything to one series. sum by (route) keeps the route. sum without (instance) keeps everything except the instance. Prefer without in code you will maintain — it survives someone adding a label.

None of this is a dialect: it is the stock 2.50.1 engine, so anything the Prometheus docs describe works the same way here.

The MCP tools

With a connection named metrics on the Prometheus engine:

Tool	What it does here
metrics_query	Runs PromQL. Instant queries and range queries both go through this.
metrics_store	Ingests exposition-format metrics.
metrics_list_tables	Enumerates metric names — the equivalent of the label-values lookup on __name__.
metrics_annotate_table	Attaches a description to a metric. Read the next section before skipping this one.

Making a model write correct PromQL

A model that can list metric names still cannot tell a counter from a gauge, and it cannot know that route is low-cardinality while instance is not. Give it both, once, per metric:

http_request_duration_seconds — histogram. Buckets at 0.005, 0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, +Inf seconds. Labels: route (about 12 values), method, status, instance. Always sum by (le, ...) before histogram_quantile. The +Inf bucket means anything above 5s is unresolvable — a p99 that reads exactly 5 means "at least 5", not "5".

render_queue_depth — gauge, jobs waiting. Never use rate() on this. Use avg_over_time for a smoothed level or deriv for a trend. Labels: pool (cpu | gpu).

Two annotations, and the model stops producing the two errors it would otherwise make on every question. This is a far better use of ten minutes than any amount of system-prompt tuning, and the descriptions stay on the connection, so every client you point at it inherits them.

Naming conventions help for free, because they are load-bearing in Prometheus culture and models have absorbed them: _total for counters, _seconds / _bytes for units, _bucket / _sum / _count for histogram parts. Follow them and half the annotation becomes unnecessary.

Recording rules and Grafana

Expressions that appear in more than one dashboard belong in a recording rule — precomputed on an interval and stored as a new series:

groups:
  - name: render-slo
    interval: 30s
    rules:
      - record: job:http_request_error_ratio:rate5m
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          / sum(rate(http_requests_total[5m]))
      - record: job:http_request_duration_seconds:p99_5m
        expr: |
          histogram_quantile(0.99,
            sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

The level:metric:operations naming convention in those record names is a Prometheus community convention, and following it makes recorded series obvious in a metric list. Full file in examples/rules.yml, alongside alert expressions you can validate here before they go anywhere near a production Alertmanager — which is genuinely one of the best uses of a free instance.

Grafana connects as an ordinary Prometheus data source using the instance URL. Existing dashboards work unchanged, assuming the metrics they reference are being written here.

Prometheus, InfluxDB or TimescaleDB?

All three are on freebase.cloud and people ask this constantly. Honestly:

• Prometheus — if your data is already Prometheus-shaped (counters, gauges, histograms, labels) and your questions are operational. PromQL's rate() semantics and counter-reset handling are genuinely better than reimplementing the same logic elsewhere. Weak at long retention, exact event counts, and anything with high-cardinality identifiers.
• InfluxDB — if you are ingesting sensor or application measurements over line protocol and want Flux's transformations, joins and scheduled downsampling. Better at heterogeneous data shapes; no equivalent of rate()'s reset handling.
• TimescaleDB — if your time-series lives next to relational data and you want real SQL, joins and continuous aggregates. Best choice when a query needs to touch both metrics and business tables; heavier to operate than either of the above.

The tie-breaker that actually decides it: what is your data being produced by? Exporters and client libraries → Prometheus. Telegraf and devices → InfluxDB. An application already writing to Postgres → TimescaleDB.

Limits, stated plainly

What the free tier is for: development, prototyping, and production workloads that stay small. It runs Prometheus 2.50.1 with the complete PromQL expression language, remote_write and remote_read, the exposition text format, recording rules, and Grafana compatibility.

There is no SLA, no stated retention guarantee and no backup promise — check the dashboard for the current retention window and quotas rather than trusting a number written in a README six months ago. Do not point a production alerting pipeline at this. Do point a staging cluster, a side project, or a "let me see whether this SLO expression is even right" experiment at it.

Client setup

ChatGPT — Settings → Apps → Advanced settings → enable developer mode → Apps → Create → paste https://freebase.cloud/api/mcp/YOUR_TOKEN, Auth None → Scan Tools → Create. The plans with documented developer mode are Pro, Plus, Business, Enterprise and Edu; unrestricted writes are still reaching Business, Enterprise and Edu workspaces, so some plans are query-only today. For this use case that is no loss — reading metrics is the whole point. (OpenAI's own docs disagree on whether the setting lives under Apps or Connectors; check both.)

OpenAI Responses API

{
  "model": "gpt-5.6",
  "tools": [{
    "type": "mcp",
    "server_label": "metrics",
    "server_description": "Prometheus metrics store — PromQL queries over service telemetry.",
    "server_url": "https://freebase.cloud/api/mcp/YOUR_TOKEN",
    "require_approval": "never"
  }],
  "input": "What was the p99 render latency over the last six hours?"
}

Warp — Settings → AI → Manage MCP servers → "Streamable HTTP or SSE Server (URL)". Warp's paste box takes the server object with no mcpServers wrapper:

{ "metrics": { "url": "https://freebase.cloud/api/mcp/YOUR_TOKEN" } }

Claude Code

claude mcp add --transport http metrics https://freebase.cloud/api/mcp/YOUR_TOKEN --scope project

--scope project writes .mcp.json, which you can commit — with the token substituted out, since it is in the URL.

Claude Desktop is UI-only for remote servers: Settings → Connectors → Add custom connector. Walkthrough: connecting Claude to Prometheus.

Reference

• PromQL basics and function reference
• Metric and label naming conventions
• Histograms and summaries — read this before choosing bucket boundaries, not after
• remote_write tuning
• Free Prometheus cloud instance

---

freebase.cloud is an independent service and is not affiliated with the Prometheus project, the Cloud Native Computing Foundation, Grafana Labs, OpenAI, Anthropic or Warp.