Autonomous SRE & Distributed Incident Diagnosis MCP Server

query_service_metrics

Query time-series telemetry for CPU, memory, 5xx error rates, and P99 latency, then detect statistical anomaly spikes to diagnose service incidents.

Instructions

Query time-series telemetry metrics (CPU, RAM, 5xx error rates, P99 latency) and detect statistical anomaly spikes.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "serviceName": "<serviceName>",
      "metricType": "<metricType>"
    },
    "name": "query_service_metrics"
  }
}

Input Schema

Name	Required	Description
`metricType`	Yes	Telemetry metric to query
`serviceName`	Yes	The target microservice name (e.g. "order-service", "payment-gateway")
`timeframeMinutes`	No	Lookback window in minutes (1 to 180, default 15)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 11, 2026

TDQS

B3.2/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose a meaningful behavioral trait beyond the name, namely that the tool computes anomaly detection over the series rather than returning raw points, but says nothing about sampling granularity, retention limits, auth requirements, or how anomalies surface in the result.

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?

One compact, front-loaded sentence with no filler; the verb and resource lead, and the metric enumeration earns its space by naming the queryable dimensions. It is dense but not padded.

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?

For a three-parameter query tool with complete schema coverage, the main remaining gap is the return contract: with no output schema, the description should say whether the response includes raw series, anomaly flags, or both. Without that, an agent cannot anticipate the result shape.

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 coverage is 100% with a full enum and an explicit 1-180 minute range with default, so the schema already carries parameter meaning. The description's parenthetical metric list loosely mirrors the enum values and adds no syntax, unit, or formatting detail beyond it.

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?

States a specific verb ("Query") and resource ("time-series telemetry metrics"), enumerates the four metric families, and adds anomaly-spike detection, so the agent knows exactly what capability this exposes. It stops short of distinguishing itself from siblings such as fetch_error_traces, leaving overlap for the agent to resolve.

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

Usage Guidelines2/5

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

There is no when-to-use, when-not-to-use, or alternative-routing guidance at all; the agent must infer that this fits incident investigation and how it differs from trace or summary siblings. Usage is only implied by the metric list, not stated.

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

Deploy Server