Skip to main content
Glama
mgcrea

mcp-prometheus

by mgcrea

Prometheus: List Metrics

prometheus_list_metrics
Read-only

Find metric names, types, and help text, and search them by name or help text before writing a PromQL query against an unfamiliar metric.

Instructions

Find metric names, with their type (counter, gauge, histogram, summary) and help text. search matches the name or the help text, so disk finds node_filesystem_avail_bytes by its description. Use this before writing a query against a metric you have not seen, then prometheus_describe_metric for its labels. Counters need rate() or increase(); summing a raw counter is the most common PromQL mistake.

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.
limitNoMaximum metrics to return (1-1000). Defaults to 100.
matchNoA series selector to restrict to, e.g. `{namespace="monitoring"}` or `up{job=~"kube.*"}`. A selector only — no functions or operators. An empty matcher set `{}` is rejected by Prometheus; use at least one non-empty matcher such as `{job=~".+"}`.
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.
searchNoCase-insensitive substring to filter by, e.g. `http`.
metadataNoInclude type and help per metric. false returns bare names, about a fifth the size.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare this as read-only, and the description adds useful behavioral context: search matches both metric name and help text, metadata=false returns much smaller bare-name output, and raw counters require rate() or increase(). It does not cover auth or rate-limit behavior, but for a read-only list tool this is substantial added context.

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 adds search semantics, workflow guidance, and a counter caveat in four efficient sentences. There is no redundant restatement of schema fields.

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?

For a six-parameter read-only listing tool with fully documented schema and no output schema, the description is complete enough: it states what is returned, how search works, when to use it, and which sibling handles labels. Remaining details such as time ranges and limits are already covered in the schema.

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 the schema already documents all six parameters. The description adds value beyond the schema by explaining that `search` matches help text as well as metric names and by clarifying the downstream label lookup path.

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 states a specific verb and resource: it finds metric names and returns their type and help text. It clearly distinguishes the tool from prometheus_describe_metric by directing label lookup to that sibling.

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 gives explicit usage guidance: use this before writing a query against an unseen metric, then use prometheus_describe_metric for labels. It also adds a relevant PromQL warning about counters, making the when-to-use guidance actionable.

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