Skip to main content
Glama
mgcrea

mcp-prometheus

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Prometheus: Query Range

prometheus_query_range
Read-only

Evaluate PromQL expressions over a time range to detect spikes, trends, or when a change started, returning per-series min, max, avg, last statistics or step values.

Instructions

Evaluate a PromQL expression over a time range, for how something changed: a spike, a trend, when it started. Each series comes back with stats (min, max, avg, last) and, with view=values, one value per step on a shared grid given by start and step (null where there was no sample) — no per-point timestamps. The step is picked for about 60 points unless given. Many series are expensive: aggregate in the query (sum by), or use view=stats with sort=max to find the outliers first.

Input Schema

NameRequiredDescriptionDefault
endNoRange end: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z) or unix seconds. Defaults to now.
sortNoOrder of series, applied before `limit` cuts: labels keeps Prometheus's order; max/avg/last rank highest first, so a cut keeps the biggest.labels
stepNoResolution, as a duration (30s, 5m, 1h) or seconds. Defaults to a round step giving about 60 points. Each series costs one value per step.
viewNovalues: stats plus the value at every step. stats: min/max/avg/last only, about a tenth of the size — use it to survey many series before plotting a few.values
limitNoMaximum series to return (1-500). Defaults to 20.
queryYesA PromQL expression, e.g. `sum by (namespace) (rate(http_requests_total{status=~"5.."}[5m]))`. Aggregate inside the expression (sum by, topk, count) rather than fetching raw series and reading them: Prometheus does the arithmetic exactly and the answer is a fraction of the size.
startNoRange start: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z) or unix seconds. Defaults to now-1h.
precisionNoSignificant digits to round fractional values to (whole numbers are never rounded). Defaults to 4; 0 returns the exact value. Raise it only when comparing values that differ past the fourth digit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover read-only and open-world, so the description carries the rest and does: it discloses the return shape (per-series min/max/avg/last stats, values on a shared grid, nulls for missing samples, no per-point timestamps) and the default resolution behavior (~60 points). It also flags a real operational trait — many series are expensive and per-step cost scales — which annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with purpose and return shape before cost guidance. Slight redundancy with the schema — the sum by example and the view=stats/sort=max tip restate parameter descriptions — but every sentence carries actionable content and none is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 parameters, no output schema, and only read-only/open-world annotations, the description fills exactly the gaps that matter: what comes back, how resolution is defaulted, and how to control result size. An agent can pick arguments and anticipate the response without opening anything else.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so 3 is the baseline; the description earns above that by explaining the interaction between step and point count, why sort=max pairs with view=stats to find outliers, and why to aggregate inside the query. It repeats some schema text (view values vs stats, sum by) but adds causal reasoning the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Evaluate a PromQL expression over a time range") and immediately qualifies the scope with the kind of question it answers (spike, trend, when it started). The phrase "over a time range" plus the shared-grid return shape cleanly separates it from an instant-query sibling without needing to name it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use framing ("for how something changed: a spike, a trend, when it started") and in-tool routing between view=values and view=stats, plus advice to aggregate before fetching. It never names an alternative tool such as an instant query or list_metrics, so the sibling routing is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools