Skip to main content
Glama
mgcrea

mcp-prometheus

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Prometheus: Describe Metric

prometheus_describe_metric
Read-only

Inspect a metric's type, help, unit, series count, and label cardinality before writing a PromQL selector. Reveals which labels to filter or group by and which are too high-cardinality.

Instructions

Everything needed to query one metric: type, help, unit, how many series it has, and each label with its number of distinct values and examples. Read this before writing a selector — it shows which labels exist to filter and group by, and whether a label is high-cardinality (pod, uid) and so a bad thing to group by.

Input Schema

NameRequiredDescriptionDefault
endNoOnly consider series with samples before this: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z) or unix seconds. Defaults to now.
startNoOnly consider series with samples after this: now, now-1h, -30m, an RFC3339 timestamp (2026-01-31T12:00:00Z) or unix seconds. Defaults to now-1h, i.e. series that exist now. Pass now-30d to include ones that have since gone away.
metricYesA metric name, e.g. `http_requests_total`. For a histogram or summary, the base name (`http_request_duration_seconds`) covers its _bucket, _count and _sum series.
examplesNoExample values to show per label (0-50). Defaults to 8.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuine behavioral value beyond that: it discloses the computed outputs (series count, distinct-value counts, examples) and calls out the practical consequence of high-cardinality labels (pod, uid) being bad group-by keys — insight an agent would otherwise have to derive itself.

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?

Two sentences, front-loaded with the return contents and then the usage rationale. Dense but every clause carries information; 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?

No output schema exists, so the description properly enumerates what comes back (type, help, unit, series count, labels with counts and examples). The only omission is that results are scoped by the start/end window, which the schema covers but the description never hints at.

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 metric naming (including histogram/summary base names), start/end time windows, and the examples count. The description adds nothing parameter-specific, so the baseline 3 applies.

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 specifically that it returns metadata for one metric: type, help, unit, series count, and per-label cardinality plus example values. This is clearly distinct from siblings like prometheus_query (executes a query) and prometheus_list_labels (enumerates label names), since the agent knows this is per-metric introspection.

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?

"Read this before writing a selector" gives explicit ordering guidance for the agent's workflow, and the high-cardinality warning steers grouping decisions. It stops short of naming alternatives (list_metrics, list_labels, list_label_values) that could be used for adjacent discovery tasks.

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