Skip to main content
Glama
mgcrea

mcp-prometheus

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Prometheus: Query

prometheus_query
Read-only

Evaluate a PromQL expression at a single instant to get current values or windowed totals/averages, so agents can answer metric questions without fetching raw series.

Instructions

Evaluate a PromQL expression at one instant — the current value of something, or a total/average over a window written into the expression (increase(x[24h]), avg_over_time(x[1h])). This is the right tool for almost every question; use prometheus_query_range only when the shape over time matters. Labels shared by every series are returned once as common_labels. Upstream order is kept, so sort_desc() and topk() rank the result; past limit the rest is cut and truncated is set.

Input Schema

NameRequiredDescriptionDefault
timeNoEvaluation time: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z) or unix seconds. Defaults to now.
limitNoMaximum series to return (1-2000). Defaults to 100. To see the largest, write topk(10, ...) into the query instead of raising this.
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.
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 already declare readOnlyHint=true and openWorldHint=true, but the description adds important behavior beyond them: shared labels are collapsed into common_labels, upstream ordering is preserved for sort_desc()/topk(), and exceeding limit truncates results and sets truncated. These are concrete output and truncation semantics that help an agent interpret results correctly.

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

Conciseness5/5

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

The description is front-loaded with the core purpose, then routes to the alternative, then explains result ordering and truncation. Every sentence carries operational value with no filler.

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

Completeness4/5

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

For a complex query tool with no output schema, the description covers the key return behaviors including common_labels, ordering, and truncation. It does not fully describe the result object shape or error behavior, but it is sufficient for an agent to invoke and interpret the main output.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents query, time, limit, and precision thoroughly, including examples and the topk() guidance. The description reinforces query shape and limit truncation but does not add syntax or constraints for time or precision beyond the schema, so it remains at the baseline for fully documented parameters.

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?

The description gives a specific verb and resource: evaluate a PromQL expression at one instant. It also distinguishes this tool from prometheus_query_range and gives concrete window examples such as increase(x[24h]), so an agent can identify the operation without opening the schema.

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

Usage Guidelines5/5

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

It explicitly says this is the right tool for almost every question and names the precise condition for using the range alternative: when the shape over time matters. That is direct when-to-use and when-not-to-use guidance against a real sibling tool.

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