Skip to main content
Glama

prom_range_query

Execute PromQL queries over specified time ranges to retrieve and analyze time series data from Prometheus monitoring systems.

Instructions

Execute a PromQL query over a time range and return series data

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesPromQL query expression
startNoStart time (ISO 8601, default: 1h ago)
endNoEnd time (ISO 8601, default: now)
stepNoQuery step (e.g., '60s', '5m', default: '60s')

Implementation Reference

  • The rangeQuery function handles the execution of Prometheus range queries, fetches data from the Prometheus API, and formats the result into a readable string.
    export async function rangeQuery(args: Record<string, unknown>): Promise<string> {
      const query = args.query as string;
      if (!query) throw new Error("PromQL query is required");
    
      const end = (args.end as string) || new Date().toISOString();
      const start = (args.start as string) || new Date(Date.now() - 3600000).toISOString();
      const step = (args.step as string) || "60s";
    
      const url = `${config.prometheusUrl}/api/v1/query_range?query=${encodeURIComponent(query)}&start=${encodeURIComponent(start)}&end=${encodeURIComponent(end)}&step=${encodeURIComponent(step)}`;
      const res = await fetch(url);
      if (!res.ok) throw new Error(`Prometheus range query failed: ${res.status}`);
    
      const data = (await res.json()) as { status: string; error?: string; data: { result: Array<{ metric: Record<string, string>; values: [number, string][] }> } };
      if (data.status !== "success") throw new Error(`Query error: ${data.error || "unknown"}`);
    
      const results = data.data.result || [];
      if (results.length === 0) return `No results for range query: ${query}`;
    
      const lines: string[] = [`Range query: ${query}`, `Period: ${start} → ${end} (step: ${step})`, ""];
    
      for (const r of results) {
        const labels = Object.entries(r.metric as Record<string, string>)
          .map(([k, v]) => `${k}="${v}"`)
          .join(", ");
        lines.push(`Metric: ${labels || "{}"}`);
    
        const values = (r.values as [number, string][]) || [];
        const first5 = values.slice(0, 5);
        const last5 = values.slice(-5);
    
        for (const [ts, val] of first5) {
          lines.push(`  ${new Date(ts * 1000).toISOString()} → ${val}`);
        }
        if (values.length > 10) {
          lines.push(`  ... (${values.length - 10} more data points) ...`);
        }
        if (values.length > 5) {
          for (const [ts, val] of last5) {
            lines.push(`  ${new Date(ts * 1000).toISOString()} → ${val}`);
          }
        }
        lines.push("");
      }
    
      return lines.join("\n");
    }
  • The MCP tool definition for 'prom_range_query', which defines its name, description, and input parameters.
    {
      name: "prom_range_query",
      description: "Execute a PromQL query over a time range and return series data",
      inputSchema: {
        type: "object" as const,
        properties: {
          query: { type: "string", description: "PromQL query expression" },
          start: { type: "string", description: "Start time (ISO 8601, default: 1h ago)" },
          end: { type: "string", description: "End time (ISO 8601, default: now)" },
          step: { type: "string", description: "Query step (e.g., '60s', '5m', default: '60s')" },
        },
        required: ["query"],
      },
    },
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the action and return type ('return series data') but lacks critical behavioral details: no information about authentication requirements, rate limits, error handling, response format, or whether this is a read-only operation. For a query tool with no annotations, this is insufficient.

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 a single, efficient sentence with zero wasted words. It's front-loaded with the core action and clearly states the purpose. Every element earns its place.

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

Completeness3/5

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

Given no annotations and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose and distinguishes from one sibling, but lacks behavioral context (auth, limits, errors) and output details. For a query tool with 4 parameters and no structured safety hints, it should do more.

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%, so the schema already fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain PromQL syntax or provide examples). Baseline 3 is appropriate when schema does all the work.

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

Purpose4/5

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

The description clearly states the action ('Execute a PromQL query') and the resource ('series data'), with the specific scope 'over a time range'. It distinguishes from sibling 'prom_instant_query' by specifying range queries, but doesn't explicitly mention all siblings like 'prom_active_alerts' or 'prom_alert_rules'.

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

Usage Guidelines3/5

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

The description implies usage for time-range queries versus instant queries (sibling 'prom_instant_query'), but doesn't explicitly state when to choose this tool over alternatives like 'prom_active_alerts' or provide any exclusion criteria. Usage context is implied rather than clearly defined.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/batu-sonmez/infraclaude'

If you have feedback or need assistance with the MCP directory API, please join our Discord server