This server provides read-only access to a Prometheus monitoring instance, enabling AI agents and MCP-capable clients to query metrics, investigate alerts, and explore scrape targets.
List Metrics (prometheus_list_metrics): Discover all metric names with optional case-insensitive substring filtering (e.g., metrics containing 'http'). Results are capped at 500 metrics.
Instant PromQL Query (prometheus_query): Execute any PromQL expression at a specific point in time (or now), returning result type, sample count, labels, timestamps, and values — ideal for checking current state.
Range PromQL Query (prometheus_query_range): Execute a PromQL expression over a time window with a specified resolution step, returning time-series data — useful for graphing trends or investigating past incidents.
List Active Alerts (prometheus_list_alerts): Retrieve all firing or pending alerts, including labels (e.g., alertname, severity), state, activation time, and current value, with a summary grouped by state and severity.
List Scrape Targets (prometheus_list_targets): Inspect all scrape targets with job name, instance address, health status (up/down/unknown), last scrape duration, and any errors — filterable by state (active, dropped, or any).
Key characteristics: All tools are strictly read-only (no risk of modifying Prometheus data), support Bearer token or HTTP Basic authentication, return structured JSON output, and are configurable via environment variables.
Provides tools for querying Prometheus metrics with PromQL, listing available metric names, inspecting active alerts, and exploring scrape targets.
MCP server for Prometheus metrics and observability. Give Claude (or any MCP-capable agent) read access to your Prometheus instance — query metrics with PromQL, inspect active alerts, and explore scrape targets — without leaving the conversation.
The existing Prometheus integrations require custom scripts or direct API knowledge. This server:
Speaks the standard Model Context Protocol over stdio — works with Claude Desktop, Claude Code, Cursor, and any MCP client.
Is read-only: all 5 tools carry readOnlyHint: true — zero risk of modifying Prometheus data.
Returns dual-channel output: structured JSON (structuredContent) for programmatic use + Markdown (content) for human-readable display.
Has actionable error messages that name the exact env var to fix and suggest a next step.
Supports Bearer token, HTTP Basic auth, or no auth (common for internal deployments).
Related MCP server: Proms MCP Server
Tool | Endpoint | Description |
|
| List all metric names with optional substring filter (cap 500) |
|
| Execute an instant PromQL query |
|
| Execute a PromQL range query returning time-series |
|
| List active and pending alerts |
|
| List scrape targets by health and job |
Version 4.0 introduces powerful new capabilities for AI agents to autonomously investigate production errors:
Automatically identify related alerts across multiple Prometheus instances
Group alerts by service identifiers to understand incident scope
Detect cascading alert patterns with directional dependency inference
Anomaly detection in metrics with automatic seasonality adjustment
Dependency chain traversal from symptoms to potential root causes
Change point detection correlating alerts with recent deployments or config changes
Ranked root cause candidates based on evidence strength and impact analysis
Dynamic service dependency maps built from traffic correlation analysis
Cross-cluster dependency visualization showing service interoperation
Synthetic health probing to assess dependency resilience
Load shedding recommendations based on dependency fragility
Historical pattern recognition for recurring alert schedules
Capacity forecasting to predict resource exhaustion
MTTR benchmarking comparing resolution times against historical data
Deviation detection triggering higher-priority notifications for pattern breaks
New federation_analyze_alerts tool combining all v4.0 features
Unified output format optimized for AI agent consumption
Comprehensive incident context in a single tool call
pip install prometheus-mcpOr run directly without installing:
uvx prometheus-mcpAll configuration is via environment variables:
Variable | Required | Default | Description |
| Yes | — | Prometheus server URL, e.g. |
| No | — | Bearer token (takes precedence over Basic auth) |
| No | — | HTTP Basic auth username |
| No | — | HTTP Basic auth password |
| No |
| Set |
Copy .env.example to .env and fill in your values.
Add to your MCP config (claude_desktop_config.json or .claude/mcp.json):
{
"mcpServers": {
"prometheus": {
"command": "prometheus-mcp",
"env": {
"PROMETHEUS_URL": "https://prometheus.example.com",
"PROMETHEUS_TOKEN": "your-token-here"
}
}
}
}Or with uvx (no install required):
{
"mcpServers": {
"prometheus": {
"command": "uvx",
"args": ["prometheus-mcp"],
"env": {
"PROMETHEUS_URL": "https://prometheus.example.com"
}
}
}
}docker run --rm -e PROMETHEUS_URL=https://prometheus.example.com prometheus-mcpOnce configured, ask Claude:
"What metrics does Prometheus have about HTTP requests?"
"What is the current request rate for the payment service?"
"Show me CPU usage over the last hour with 5-minute resolution"
"Are there any firing alerts? What's their severity?"
"Which scrape targets are currently down and why?"
"How many node-exporter instances are up?"
prometheus_list_metricsReturns all metric names Prometheus knows about. Use pattern to filter by substring (case-insensitive). Start here when you don't know which metrics are available. Output is capped at 500 metrics with a truncation hint.
prometheus_queryExecute an instant PromQL expression and get current values. Returns result type (vector/scalar/matrix/string), sample count, and per-sample labels and values.
Parameters:
query (required) — PromQL expression, e.g. up, rate(http_requests_total[5m])
time (optional) — RFC3339 or Unix timestamp; defaults to now
prometheus_query_rangeExecute a PromQL expression over a time window. Returns one series per matching time series with timestamped values. Total data points across all series are capped at 5000.
Parameters:
query (required) — PromQL expression
start / end (required) — RFC3339 or Unix timestamps
step (required) — resolution like 15s, 1m, 5m
Prometheus rejects steps that would produce > 11,000 points per series (HTTP 422). Increase step or narrow the range if this happens.
Note: The Prometheus range API does not support filtering by branch or commit — filters are expressed purely in PromQL label matchers.
prometheus_list_alertsReturns all active/pending alerts with labels (including alertname, severity), state, activation time, and current value. Includes a state summary (firing vs pending counts).
prometheus_list_targetsReturns scrape targets with job name, instance address, health (up/down/unknown), last scrape duration in milliseconds, and any error message. Includes a per-job summary. Filter by state: active (default), dropped, or any.
All tools use a single persistent requests.Session with connection pooling.
The session has trust_env = False to bypass environment proxies (Prometheus is typically an internal service).
Requests time out after 30 seconds.
prometheus_query_range caps output at 5000 total points across all series — use a larger step for long windows.
prometheus_list_metrics returns up to 500 metrics after filtering.
git clone https://github.com/mshegolev/prometheus-mcp
cd prometheus-mcp
pip install -e '.[dev]'
pytest tests/ -v
ruff check src tests
ruff format src testsThis project includes an OpenAPI 3.0 specification in the specs/ directory that documents all MCP tools exposed by the server.
To validate the specification:
python3 specs/validate_spec.pyThis repository includes automated scripts and GitHub Actions workflows to streamline the release process:
scripts/auto-commit-push.sh - Automatically commit and push changes with optional release trigger
scripts/release.sh - Full release automation including pipeline checking, version bumping, and tagging
post-push-check.yml - Monitors test pipeline status after each push and comments on the commit
auto-release.yml - Manual workflow to create releases with version bumping (patch, minor, or major)
To trigger an automated release:
Go to the Actions tab in GitHub
Select "Auto Release" workflow
Run the workflow with your preferred version bump type
MIT — see LICENSE.
Get Alertmanager cluster status, version, and config.
Wraps GET /api/v2/status. Returns cluster state (ready/settling),
version info, uptime, and the raw configuration YAML.
Examples:
- Use when: "Is Alertmanager healthy?"
→ check cluster_status.
- Use when: "What version of Alertmanager is running?"
→ check version_info.
- Don't use when: You want to see active alerts
(call alertmanager_list_alerts).
Returns:
dict with cluster_status / version_info / uptime /
config_yaml.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No |
| Name | Required | Description |
|---|---|---|
| uptime | Yes | |
| config_yaml | Yes | |
| version_info | Yes | |
| cluster_status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true, idempotentHint true, destructiveHint false. The description adds value by detailing the API endpoint (GET /api/v2/status), the return fields (cluster_status, version_info, uptime, config_yaml), and the dict format. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose sentence, API reference, usage examples with when/not, and return format. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one optional parameter and output schema present, the description covers return values and usage context completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one optional parameter 'instance' with default null and no schema description. The description does not explain what this parameter does or how it affects the request. With 0% schema coverage, the description should compensate, but it does not mention the parameter at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets Alertmanager cluster status, version, and config, with specific fields listed. It distinguishes from sibling tools by explicitly saying what not to use it for (active alerts) and referencing a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' and 'Don't use when' examples, such as checking health or version, and directs to alertmanager_list_alerts for active alerts. This gives clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List alert groups from Alertmanager showing routing topology.
Wraps GET /api/v2/alerts/groups. Returns groups with their labels,
receiver, and alert count — shows how alerts are grouped for notification.
Examples:
- Use when: "Why did I get one notification instead of many?"
→ check which alerts are in the same group.
- Use when: "What receiver handles payment alerts?"
→ find the group and check its receiver.
- Don't use when: You want individual alert details
(call alertmanager_list_alerts).
Returns:
dict with total_groups / total_alerts / groups
(list with labels, receiver, alert_count).
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No |
| Name | Required | Description |
|---|---|---|
| groups | Yes | |
| total_alerts | Yes | |
| total_groups | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. Description adds context about wrapping a GET API endpoint and returning grouping logic with labels, receiver, and alert count, supplementing the annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with bullet points and examples, each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema existence is hinted, and description details the return structure. However, the undocumented parameter reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one optional parameter 'instance' with no description (0% coverage). The description does not mention or explain this parameter, leaving its purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists alert groups showing routing topology, and distinguishes from sibling tool alertmanager_list_alerts by specifying it returns grouped information rather than individual alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit examples of when to use (e.g., checking grouping for notifications) and when not to use (when individual alert details needed), including a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List alerts from Alertmanager with suppression state.
Wraps GET /api/v2/alerts. Returns alerts with their status
(active/suppressed/unprocessed), silence IDs, and inhibition IDs.
Unlike prometheus_list_alerts, this shows WHY an alert is or
isn't firing — suppressed alerts include silencedBy and
inhibitedBy arrays.
Examples:
- Use when: "Why isn't the HighCPU alert firing?"
→ check if it's suppressed (silencedBy or inhibitedBy).
- Use when: "Show all suppressed alerts"
→ filter by status.state == 'suppressed'.
- Don't use when: You want Prometheus-side alert state
(call prometheus_list_alerts).
Returns:
dict with total_count / active_count / suppressed_count /
unprocessed_count / alerts (list with status, silencedBy, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No |
| Name | Required | Description |
|---|---|---|
| alerts | Yes | |
| total_count | Yes | |
| active_count | Yes | |
| suppressed_count | Yes | |
| unprocessed_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, etc. Description adds valuable context about return structure (counts, suppressed details) and how suppressed alerts include silencedBy/inhibitedBy arrays, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: first sentence states purpose, then explains differences, provides examples, and lists return fields. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (one optional param) and presence of output schema, the description covers purpose, usage, return format, and contrasts with a sibling, making it complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'instance' is not described at all in the description, despite 0% schema coverage. The description focuses entirely on output and usage, neglecting the input parameter, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List alerts from Alertmanager with suppression state', specifies the API endpoint, and contrasts with sibling tool prometheus_list_alerts, making the purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' and 'Don't use when' examples, including a specific scenario (why a high CPU alert isn't firing) and directs to prometheus_list_alerts for Prometheus-side alert state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all silences from Alertmanager.
Wraps GET /api/v2/silences. Returns silences with matchers, status
(active/pending/expired), creator, comment, and time bounds.
Use this to understand which alerts are currently silenced and why.
During incident handoffs, knowing what's silenced is critical — a
silenced alert is invisible in Prometheus /alerts.
Examples:
- Use when: "Is the HighCPU alert silenced?"
→ search silences for matching matchers.
- Use when: "Who silenced alerts for the payment service?"
→ check createdBy and comment.
- Don't use when: You want active firing alerts
(call alertmanager_list_alerts).
Returns:
dict with total_count / active_count / pending_count /
expired_count / silences (list with matchers, status, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No | ||
| instances | No |
| Name | Required | Description |
|---|---|---|
| silences | Yes | |
| total_count | Yes | |
| active_count | Yes | |
| expired_count | Yes | |
| pending_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds context that a silenced alert is invisible in Prometheus /alerts, which is useful behavioral insight. However, it does not mention potential edge cases like pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement, the API endpoint, return details, usage guidance, and examples. Every sentence adds value, and it is appropriately brief for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no required, has output schema), the description covers purpose, usage, and return values adequately. However, the lack of parameter semantics creates a notable gap, making it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the parameters 'instance' and 'instances' are undocumented in the schema. The description fails to explain these optional parameters or how they affect the query, leaving the agent without guidance on filtering by instance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all silences from Alertmanager' with a clear verb and resource. It differentiates from sibling tool alertmanager_list_alerts by noting when not to use it, ensuring no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios with concrete examples ('Is the HighCPU alert silenced?') and a clear don't-use case ('Don't use when: You want active firing alerts (call alertmanager_list_alerts)'). This guides the agent effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Correlate alerts across multiple Prometheus instances.
Identifies related alerts that fire simultaneously or in sequence across different Prometheus instances using temporal windows and label similarity.
Use this to:
Understand cross-instance incident scope
Identify related alerts in different clusters/regions
Detect systemic issues affecting multiple instances
Examples: - "Are there related alerts firing across our US and EU clusters?" - "Show me alerts that might be related to this HighCPU alert"
Returns: CorrelationResult with correlated alerts, groups, and cascades.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No | ||
| instances | No | ||
| enable_rca | No | Enable root cause analysis enhancement (default: False) | |
| temporal_window | No | Time window in seconds for correlation (default: 300) | |
| similarity_threshold | No | Minimum similarity score for correlation (default: 0.7) |
| Name | Required | Description |
|---|---|---|
| groups | Yes | |
| cascades | Yes | |
| rca_enhancement | Yes | |
| correlated_alerts | Yes | |
| total_correlations | Yes | |
| instance_attribution | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by explaining the method (temporal windows and label similarity) and what is returned (CorrelationResult with groups and cascades). No contradictions or hidden side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, method explanation, bulleted use cases, examples, and return value specification. No unnecessary sentences; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, cross-instance correlation) and the presence of an output schema, the description covers purpose, usage, and method well. However, it fails to explain the distinction between the 'instance' and 'instances' parameters, which is important for correct invocation. Overall, still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 3 of 5 parameters (enable_rca, temporal_window, similarity_threshold) adequately. However, the two pivotal parameters 'instance' and 'instances' lack descriptions, and the description does not clarify their relationship (e.g., single vs list, mutual exclusivity). This is a gap that could lead to incorrect usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Correlate alerts across multiple Prometheus instances'. It uses a specific verb (correlate) and resource (alerts across instances), and distinguishes itself from siblings like detect_cascading_alerts which likely operates within a single instance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: understanding cross-instance incident scope, identifying related alerts in different clusters/regions, detecting systemic issues. It also gives example queries. However, it does not explicitly mention when not to use or directly point to alternatives, though the context of siblings implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect cascading alert patterns with directional dependency inference.
Identifies alert propagation patterns that indicate dependency failures.
Use this to:
Trace failure propagation paths through your system
Identify root cause candidates for complex incidents
Understand service dependency relationships
Examples: - "What alerts typically fire after DatabaseConnectionFailed?" - "Show me the failure propagation chain in this incident"
Returns: CascadeDetectionResult with detected cascades and root causes.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No | ||
| instances | No | ||
| temporal_window | No | Time window in seconds for cascade detection (default: 300) |
| Name | Required | Description |
|---|---|---|
| cascades | Yes | |
| root_causes | Yes | |
| total_cascades | Yes | |
| rca_enhancement | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds that it infers directional dependencies and returns root cause candidates, providing context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise: uses bullet points and examples without fluff. Front-loaded with purpose and use cases. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, annotations cover safety. However, missing parameter descriptions for instance/instances and no guidance on default behavior when both are null. Adequate but not fully comprehensive for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers only 33% (temporal_window has description). Description does not explain 'instance' or 'instances' parameters. No additional parameter guidance beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool detects cascading alert patterns with directional dependency inference. Differentiates from sibling tools like alertmanager_list_alerts by focusing on propagation patterns. Examples illustrate typical use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists use cases (trace propagation paths, identify root causes, understand dependencies) and provides example queries. Lacks explicit instructions on when NOT to use this tool, but scenarios are well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured Prometheus and Alertmanager instances with health status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| instances | Yes | |
| total_count | Yes | |
| federation_enabled | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only and idempotent behaviors. The description adds that health status is included, which is useful context. However, it does not disclose potential behavioral details such as pagination or caching, but given the simplicity of a list operation with no parameters, the coverage is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is complete. It specifies the scope (configured instances) and the included information (health status), which is sufficient for an agent to understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100%. According to guidelines, the baseline is 4. The description does not need to add parameter meaning, and it correctly omits any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all configured Prometheus and Alertmanager instances with health status', making it specific and distinct from sibling tools that focus on individual components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use (listing federation instances) and the sibling tools are all either Prometheus- or Alertmanager-specific, so the agent can infer this is the correct tool for federation-level queries. No explicit exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Group alerts by service identifiers across all instances.
Clusters related alerts into service-level incident analysis bundles.
Use this to:
Understand which services are affected by current incidents
Focus incident response efforts on specific service teams
Identify services with multiple simultaneous alerts
Examples: - "Which services are currently experiencing alerts?" - "Group all alerts by service for my incident report"
Returns: AlertGroupResult with alerts grouped by service identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No | ||
| instances | No |
| Name | Required | Description |
|---|---|---|
| groups | Yes | |
| total_groups | Yes | |
| rca_enhancement | Yes | |
| ungrouped_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, indicating a safe read-only operation. The description adds that it groups alerts and returns AlertGroupResult, but does not disclose potential side effects (none expected), rate limits, or pagination. The additional behavioral context is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose statement, bullet-pointed use cases, examples, and return type. No redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (cover return type) and annotations (cover safety), the description covers purpose and usage well. However, the lack of parameter documentation is a notable gap that affects completeness. Overall adequate but with clear deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'instance' or 'instances' parameters. Their meaning (filtering vs. all instances) is ambiguous. The agent must infer from default null values and tool name. This is a significant gap for effective parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'group' with resource 'alerts by service', clearly stating its function. It distinguishes from sibling tools like alertmanager_list_alert_groups (which lists groups without service-level grouping) and alertmanager_list_alerts. Examples further clarify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this to' section provides explicit scenarios (understand affected services, focus response, identify services with multiple alerts). However, it does not mention when not to use it or suggest alternative tools. For better guidance, it could note that for listing all alerts without grouping, alertmanager_list_alerts is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Prometheus build information.
Wraps GET /api/v1/status/buildinfo. Returns version, Go version,
Git revision, branch, build user, and build date.
Examples:
- Use when: "What version of Prometheus is running?" → check version.
- Use when: Debugging version-specific behavior.
- Don't use when: You want runtime stats
(call prometheus_get_runtime_info).
Returns:
dict with version / revision / branch / buildUser /
buildDate / goVersion.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No |
| Name | Required | Description |
|---|---|---|
| branch | Yes | |
| version | Yes | |
| revision | Yes | |
| buildDate | Yes | |
| buildUser | Yes | |
| goVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds value by detailing the wrapped endpoint and exact return fields, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, efficient use of sentences, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple info tool with one optional parameter and an output schema, the description fully covers purpose, usage, and return fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, and the description does not explain the optional 'instance' parameter, leaving its purpose unclear for a new user.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets Prometheus build information, lists specific fields returned, and distinguishes from siblings by mentioning not to use for runtime stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use and when not to use examples, including a named alternative tool (prometheus_get_runtime_info).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get TSDB statistics and cardinality data from Prometheus.
Wraps GET /api/v1/status/tsdb. Returns head stats (total series,
chunks, time range) and top-N lists: metrics by series count, labels
by value count, and labels by memory usage.
Use this to investigate cardinality explosions — the #1 operational Prometheus problem. High series counts slow queries and increase memory.
Examples:
- Use when: "Why is Prometheus using so much memory?"
→ check num_series and top_metrics_by_series.
- Use when: "Which labels have the most values?"
→ check top_labels_by_value_count.
- Don't use when: You want current metric values
(call prometheus_query).
Returns:
dict with num_series / chunk_count / min_time / max_time /
top_metrics_by_series / top_labels_by_value_count /
top_labels_by_memory_bytes.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No |
| Name | Required | Description |
|---|---|---|
| max_time | Yes | |
| min_time | Yes | |
| num_series | Yes | |
| chunk_count | Yes | |
| num_label_pairs | Yes | |
| top_metrics_by_series | Yes | |
| top_labels_by_value_count | Yes | |
| top_labels_by_memory_bytes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. Description adds context about the underlying GET endpoint and operational significance. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear structure: purpose, endpoint, examples, and return format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive except for missing explanation of the 'instance' parameter. Otherwise, purpose, usage, behavior, and return values are well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one optional parameter 'instance' with 0% schema description coverage. Description does not explain what 'instance' refers to or how to use it, leaving a gap for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets TSDB statistics and cardinality data, specifies the wrapped API endpoint, and lists returned fields. It distinguishes from sibling tools like prometheus_query by focusing on cardinality rather than current metric values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use case: investigate cardinality explosions. Provides example scenarios with specific queries and indicates when not to use (when wanting current metric values, pointing to prometheus_query).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metric metadata (HELP text, TYPE, UNIT) from Prometheus.
Wraps GET /api/v1/metadata. Returns the metadata that Prometheus
scraped from HELP, TYPE, and UNIT lines in the exposition
format. Each metric may have multiple metadata entries if different
scrape targets expose different help strings.
Use this to understand what a metric measures, its type (counter, gauge,
histogram, summary), and unit — essential for writing correct PromQL.
For example, knowing a metric is a counter means you should use rate()
or increase(); a gauge can be used directly.
Examples:
- Use when: "What does http_requests_total measure?"
→ metric='http_requests_total'; read help and type.
- Use when: "Show me all histogram metrics"
→ call with no filter; filter results where type='histogram'.
- Use when: Starting an investigation — check metric types before
writing PromQL to avoid using rate() on a gauge.
- Don't use when: You already know the metric type and want to
query values (call prometheus_query directly).
Returns:
dict with metric / total_count / returned_count /
truncated / metadata (dict of metric name → list of
{type, help, unit}).
| Name | Required | Description | Default |
|---|---|---|---|
| metric | No | Optional metric name to filter metadata. Example: 'http_requests_total' returns metadata only for that metric. Leave empty to list metadata for all metrics (capped at 500). | |
| instance | No | Target instance name (omit for default instance) |
| Name | Required | Description |
|---|---|---|
| metric | Yes | |
| metadata | Yes | |
| truncated | Yes | |
| total_count | Yes | |
| returned_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and openWorld hints. The description adds detail beyond this, such as wrapping the GET /api/v1/metadata endpoint, the possibility of multiple metadata entries per metric, and the return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a one-line summary, a technical detail paragraph, usage guidance, and examples. Every sentence provides value, and it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema covers all parameters and the description details the output format and edge cases (multiple entries), the tool is fully explained. The presence of an output schema description in the text further completes understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context for the 'metric' parameter with examples and default behavior (capped at 500). The 'instance' parameter is only described in the schema, but overall the description enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves metric metadata (HELP, TYPE, UNIT) from Prometheus. It distinguishes itself from sibling tools like prometheus_query by explicitly noting it is for understanding metric types, not for querying values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use and when-not-to-use examples, such as using it to check metric types before writing PromQL, and warns against using it when the metric type is already known, directing to prometheus_query instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Prometheus runtime information.
Wraps GET /api/v1/status/runtimeinfo. Returns operational data:
goroutine count, time series count, storage retention policy,
start time, corruption count, and config reload status.
Examples:
- Use when: "Why is Prometheus slow?" → check goroutine count
and time series count.
- Use when: "What's the retention policy?" → check storage_retention.
- Don't use when: You want the Prometheus version
(call prometheus_get_build_info).
Returns:
dict with start_time / goroutine_count / time_series_count /
storage_retention / corruptionCount / reloadConfigSuccess /
lastConfigTime.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No |
| Name | Required | Description |
|---|---|---|
| start_time | Yes | |
| lastConfigTime | Yes | |
| corruptionCount | Yes | |
| goroutine_count | Yes | |
| storage_retention | Yes | |
| time_series_count | Yes | |
| reloadConfigSuccess | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context by specifying the API endpoint (GET /api/v1/status/runtimeinfo) and listing return fields, consistent with annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with clear examples, returned fields list, and no redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing parameter documentation, the tool has only one optional parameter and an output schema exists. Description covers purpose, usage, and return fields sufficiently for a read-only info tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'instance' with 0% documentation coverage. The description does not mention or explain this parameter, leaving the agent without guidance on its usage or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get Prometheus runtime information' and lists specific data fields like goroutine count, time series count, retention policy. It distinguishes from sibling tool prometheus_get_build_info by specifying when not to use it, ensuring clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete examples of when to use (checking why Prometheus is slow, retention policy) and explicit exclusion (for version info, use sibling tool). This helps the agent select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Prometheus liveness and readiness.
Calls GET /-/healthy and GET /-/ready — management endpoints
outside the /api/v1 namespace. Returns whether each probe returned
a 200 status code.
Use this to verify Prometheus is actually running before investigating blank query results. A failed health check means Prometheus is down; a failed readiness check means it's starting up or shutting down.
Examples:
- Use when: "Why are all my queries returning empty results?"
→ check if Prometheus is healthy first.
- Use when: Setting up a new MCP connection — verify the target
is reachable and healthy.
- Don't use when: You want metric values (call prometheus_query).
Returns:
dict with healthy (bool), healthy_status_code,
ready (bool), ready_status_code.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No |
| Name | Required | Description |
|---|---|---|
| ready | Yes | |
| healthy | Yes | |
| ready_status_code | Yes | |
| healthy_status_code | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral context by detailing the specific endpoints, that they are outside /api/v1, and that it returns boolean statuses plus status codes. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections for endpoints, return format, usage examples, and a clear 'Don't use' guideline. It is concise, with no superfluous text, and each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers usage, behavior, and return values, it misses documenting the optional 'instance' parameter. Given the tool's simplicity (one parameter, existing output schema, and rich annotations), the description is mostly complete but has a notable gap in parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'instance' with 0% schema description coverage, but the description does not explain what 'instance' does or how to use it. For a tool with a single parameter, this omission forces the agent to guess, which could lead to incorrect invocations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check Prometheus liveness and readiness.' It specifies the endpoints called (GET /-/healthy and GET /-/ready) and the action (returns whether each probe returned a 200). This distinguishes it from sibling tools like prometheus_query, which retrieves metric values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance, including when to use ('verify Prometheus is actually running before investigating blank query results') and when not to use ('Don't use when: You want metric values (call prometheus_query)'). It includes concrete examples, making it clear for an AI agent when to invoke this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active and pending alerts from Prometheus.
Wraps GET /api/v1/alerts. Returns every alert that Prometheus currently
tracks, with labels (including alertname, severity), state
(firing / pending), the time it became active, and its current value.
Also returns a summary grouped by state and a count by severity label.
Examples:
- Use when: "Are there any firing alerts right now?"
→ check firing_count and alerts where state='firing'.
- Use when: "Show me all critical alerts"
→ filter alerts by labels.severity == 'critical'.
- Use when: Checking system health during an incident — list alerts
first to understand what's firing before querying metrics.
- Don't use when: You want historical alert data (Prometheus stores only
current state; use Alertmanager or a recording rule for history).
- Don't use when: You want raw metric values
(call prometheus_query or prometheus_query_range).
Returns:
dict with total_count / firing_count / pending_count /
state_summary / alerts (list with labels, annotations,
state, active_at, value). Enhanced with correlation
information when requested.
| Name | Required | Description | Default |
|---|---|---|---|
| instance | No | Target instance name (omit for default instance) | |
| correlation_context | No | Optional correlation context ID from federation_analyze_alerts for enhanced alert analysis. | |
| include_correlation_info | No | Include correlation-relevant information in output. |
| Name | Required | Description |
|---|---|---|
| alerts | Yes | |
| total_count | Yes | |
| firing_count | Yes | |
| pending_count | Yes | |
| state_summary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral details: wraps GET /api/v1/alerts, returns current state only, and includes correlation info when requested. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, API detail, response fields, and examples. Front-loaded with purpose. Slightly lengthy but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is described in detail, the tool is simple, and annotations cover safety, the description is complete. Includes alternatives and usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The description adds minimal new info about parameters, mainly showing usage patterns in examples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all active and pending alerts from Prometheus, specifying the API endpoint and response structure. It distinguishes from sibling tools like alertmanager_list_alerts by noting that Prometheus only stores current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' and 'Don't use when' examples, including when to use (checking firing alerts, critical alerts, during incidents) and when not (historical data, raw metrics), with alternatives like Alertmanager and prometheus_query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all values for a specific label from Prometheus.
Wraps GET /api/v1/label/{label_name}/values. Returns all distinct
values for the named label across all time series, optionally filtered
by a series selector.
Use this to discover what entities exist for a given label dimension — for example, which jobs are running, which instances are scraped, or which namespaces have metrics. This is essential for building targeted PromQL queries during investigation.
Examples:
- Use when: "What jobs does Prometheus scrape?"
→ label='job'; read the values list.
- Use when: "What instances are in the 'node-exporter' job?"
→ label='instance', match='{job="node-exporter"}'.
- Use when: "What namespaces have metrics?"
→ label='namespace'.
- Don't use when: You want metric names
(call prometheus_list_metrics — has substring filtering).
- Don't use when: You want current metric values
(call prometheus_query with a PromQL expression).
Returns:
dict with label / match / total_count /
returned_count / truncated / values (sorted list).
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Label name to retrieve values for. Examples: 'job' (list all job names), 'instance' (list all instances), '__name__' (list all metric names — same as prometheus_list_metrics). | |
| match | No | Optional series selector to restrict which series the label values come from. Example: 'up' returns label values only from the 'up' metric. Example: '{job="node"}' returns label values only from the node job. Leave empty to get values across all series. | |
| instance | No | Target instance name (omit for default instance) |
| Name | Required | Description |
|---|---|---|
| label | Yes | |
| match | Yes | |
| values | Yes | |
| truncated | Yes | |
| total_count | Yes | |
| returned_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds context about the API endpoint, optional filtering, and the return structure (label, match, total_count, etc.), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with examples and bullet points, though slightly verbose. It earns its place by being informative and actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present (return dict described), moderate complexity, and full annotation coverage, the description is complete: it covers purpose, parameter usage, return format, and differentiation from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds real-world examples for label and match parameters, explaining how to use them for typical investigations, which provides value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all values for a specific label from Prometheus, wrapping the GET /api/v1/label/{label_name}/values endpoint. It distinguishes from sibling tools by explicitly naming alternatives (prometheus_list_metrics, prometheus_query) and explaining when not to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use examples ('What jobs does Prometheus scrape?') and when-not-to-use cases with specific alternative tools, making it easy for the agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all metric names known to Prometheus, with optional substring filter.
Wraps GET /api/v1/label/__name__/values. Prometheus returns all metric
names at once — no pagination. Output is capped at 500 metrics after filtering,
with a truncation hint when more exist.
Use this first to discover valid metric names before writing PromQL
expressions for prometheus_query or prometheus_query_range.
Examples:
- Use when: "What metrics does Prometheus have about HTTP requests?"
→ pattern='http'; read the metrics list.
- Use when: "List all node_exporter metrics"
→ pattern='node_'.
- Use when: Starting a monitoring investigation — list metrics first
to discover what's instrumented, then query specific ones.
- Don't use when: You already know the exact metric name and want to
query its value (call prometheus_query directly — one fewer round trip).
- Don't use when: You want to see current alert state
(call prometheus_list_alerts).
Returns:
dict with total_count / returned_count / truncated /
pattern / metrics (sorted list).
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Optional substring filter applied case-insensitively to metric names. Example: 'http' returns all metrics containing 'http' in their name. Leave empty to list all metrics (capped at 500). | |
| instance | No | Target instance name (omit for default instance) |
| Name | Required | Description |
|---|---|---|
| metrics | Yes | |
| pattern | Yes | |
| truncated | Yes | |
| total_count | Yes | |
| returned_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavior beyond annotations: wraps a specific API, no pagination, cap of 500 metrics with truncation hint, case-insensitive filtering. Annotations already indicate read-only, idempotent, non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured, front-loaded with core purpose, followed by implementation detail, usage guidance, examples, and return format. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple; description covers behavior, constraints, usage scenarios, and return format comprehensively. Output schema is described inline. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with detailed descriptions (100% coverage). The description adds context like capping and example usage, but parameter meaning is already clear from schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all metric names with optional substring filter, and distinguishes from sibling tools like prometheus_query and prometheus_list_alerts by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use (discovery before querying) and when-not-to-use (if metric name is known, use prometheus_query; for alerts, use prometheus_list_alerts), with concrete examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recording and alerting rules from Prometheus.
Wraps GET /api/v1/rules. Returns rule groups with their rules,
including the PromQL expression, rule type (recording or alerting),
and for alerting rules their current state (firing/pending/inactive).
Use this to understand the alerting configuration, find recording rules that pre-compute useful aggregations, and investigate which rules are currently firing or have health issues.
Examples:
- Use when: "What alerting rules are configured?"
→ type='alert'; inspect rule names and expressions.
- Use when: "Are there any recording rules I can use instead of
computing aggregations from scratch?"
→ type='record'; look for rules matching your investigation.
- Use when: "Why is this alert firing? What's its PromQL expression?"
→ call with no filter; find the alert by name; read its query.
- Don't use when: You want to see which alerts are currently
firing (call prometheus_list_alerts — shows active alerts with
state and value, without the PromQL definition).
Returns:
dict with type_filter / total_groups / total_rules /
recording_count / alerting_count / groups (list of
rule groups with name, file, rule_count, rules).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional filter by rule type: 'alert' for alerting rules only, 'record' for recording rules only. Leave empty for both types. | |
| instance | No | Target instance name (omit for default instance) |
| Name | Required | Description |
|---|---|---|
| groups | Yes | |
| total_rules | Yes | |
| type_filter | Yes | |
| total_groups | Yes | |
| alerting_count | Yes | |
| recording_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context beyond annotations by specifying it wraps a GET request and detailing the return structure (rule groups with rules, PromQL expressions, states). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with front-loaded single sentence stating purpose, followed by API wrap detail, then bullet examples and return dict summary. Every sentence adds value, and it's appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters, output schema exists), the description fully covers purpose, usage, behavioral traits, and return structure. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds some contextual value by explaining the purpose of the 'type' filter via examples, but does not add new syntactic or semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists recording and alerting rules from Prometheus, specifying the verb 'List' and resource 'rules'. It distinguishes from sibling tool 'prometheus_list_alerts' by noting that this tool shows rule definitions, not active alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use examples (e.g., 'What alerting rules are configured?') and a 'Don't use when' with the alternative tool 'prometheus_list_alerts', giving clear guidance on when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Prometheus scrape targets, summarised by job and health.
Wraps GET /api/v1/targets. Returns scrape targets with job name,
instance address, health status (up / down / unknown),
last scrape duration in milliseconds, and any last error. Also returns
a summary grouped by job and health state.
Examples:
- Use when: "Which targets are currently down?"
→ filter targets where health='down' and check last_error.
- Use when: "How many instances of the 'node-exporter' job are up?"
→ check job_summary for the 'node-exporter' entry.
- Use when: Investigating a scrape failure — list targets for the
affected job to see which instances have errors.
- Don't use when: You want metric values from a target
(call prometheus_query with label matchers instead).
- Don't use when: You want alert status
(call prometheus_list_alerts instead).
Returns:
dict with state_filter / total_count / up_count /
down_count / unknown_count / job_summary (per-job health counts) /
targets (list with job, instance, health,
last_scrape_duration_ms, last_error, labels).
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Filter targets by state: 'active' (default, scrape targets Prometheus is scraping), 'dropped' (targets that were dropped by relabelling), or 'any' (all targets regardless of state). | active |
| instance | No | Target instance name (omit for default instance) |
| Name | Required | Description |
|---|---|---|
| targets | Yes | |
| up_count | Yes | |
| down_count | Yes | |
| job_summary | Yes | |
| total_count | Yes | |
| state_filter | Yes | |
| unknown_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Beyond that, description adds that it wraps a specific API endpoint, returns a summary grouped by job and health, and lists fields of the return dictionary. This provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, API reference, examples, returns). It is slightly lengthy but each sentence provides value, and the examples are particularly helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (wrapping an API, returning both a list and summary), the description covers purpose, usage, return format, and examples. An output schema exists, so the description need not fully document return values, yet it still provides an overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add significant meaning beyond what the schema already provides for the parameters, focusing instead on usage examples and return values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List Prometheus scrape targets, summarised by job and health.' It is a specific verb+resource and distinguishes from siblings like prometheus_list_alerts and prometheus_query through 'Don't use when' guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use examples (e.g., 'Which targets are currently down?') and when-not-to-use with alternative tool names (e.g., call prometheus_query instead). This clearly guides appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an instant PromQL query against Prometheus.
Wraps GET /api/v1/query. Returns the result type (vector, scalar,
matrix, string) and a list of samples each carrying labels, timestamp,
and value. For vector results each element is one time series at the
evaluation instant.
Examples:
- Use when: "Is the payment service up right now?"
→ query='up{job="payment-service"}'.
- Use when: "What is the current HTTP request rate?"
→ query='sum(rate(http_requests_total[5m])) by (job)'.
- Use when: "Show me all metrics for a specific instance"
→ query='{instance="localhost:9090"}'.
- Don't use when: You want to see how a metric changed over time
(call prometheus_query_range with start/end/step).
- Don't use when: You don't know the metric name yet
(call prometheus_list_metrics first to discover names).
Returns:
dict with query / time / result_type / result_count /
data (list of samples with labels, timestamp, value).
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | Evaluation timestamp (optional). RFC3339 (e.g. '2024-01-15T10:00:00Z') or Unix timestamp (e.g. '1705312800'). Defaults to now. | |
| query | Yes | PromQL expression to evaluate. Examples: 'up', 'rate(http_requests_total[5m])', 'sum(rate(http_requests_total[5m])) by (job)'. | |
| instance | No | Target instance name (omit for default instance) |
| Name | Required | Description |
|---|---|---|
| data | Yes | |
| time | Yes | |
| query | Yes | |
| result_type | Yes | |
| result_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds detail about the return format (result type, samples with labels/timestamp/value) and response structure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections and examples. Every sentence adds value, but it is somewhat lengthy. Front-loads the core purpose and provides structured examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of PromQL queries and the presence of an output schema describing the return structure, the description covers everything needed: purpose, usage, parameters, return format, and examples. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already documents parameters well. The description adds value with usage examples that illustrate parameter values (e.g., time format, query examples) and clarifies the 'instance' parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes an instant PromQL query against Prometheus, wrapping the GET /api/v1/query endpoint. It distinguishes from sibling tools like prometheus_query_range and prometheus_list_metrics with specific usage examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use when' and 'Don't use when' examples, pointing to alternative tools for range queries and metric discovery. This gives clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a PromQL range query returning time-series data points.
Wraps GET /api/v1/query_range. Returns one series per matching time
series, each with labels and a list of [timestamp, value] pairs.
Total points across all series are capped at 5000 with a truncation hint.
Prometheus may reject the query with HTTP 422 (bad_data) if the step produces too many data points (> 11,000 per series). Increase the step or narrow the time range if this happens.
Note: The Prometheus API does not support filtering by branch or commit in this endpoint — filters are expressed purely in PromQL label matchers.
Examples:
- Use when: "Show me CPU usage over the last hour with 1-minute resolution"
→ query='rate(node_cpu_seconds_total[5m])', step='1m'.
- Use when: "Graph HTTP error rate for the last 24 hours"
→ query='rate(http_requests_total{status=~"5.."}[5m])',
start='2024-01-15T00:00:00Z', end='2024-01-16T00:00:00Z',
step='5m'.
- Use when: Investigating a past incident — pick the time window of the
incident and use a fine step.
- Don't use when: You only want the current value
(call prometheus_query — faster and simpler).
- Don't use when: You want alert history (call prometheus_list_alerts).
Returns:
dict with query / start / end / step / result_type /
series_count / total_points / truncated /
data (list of series with labels, point_count, values).
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End of range. RFC3339 (e.g. '2024-01-15T11:00:00Z') or Unix timestamp (e.g. '1705316400'). | |
| step | Yes | Query resolution step. Duration string (e.g. '15s', '1m', '5m') or float seconds (e.g. '30'). Prometheus rejects steps that produce more than 11,000 data points per series. | |
| query | Yes | PromQL expression to evaluate over a time range. Examples: 'rate(http_requests_total[5m])', 'node_cpu_seconds_total{mode="idle"}'. | |
| start | Yes | Start of range. RFC3339 (e.g. '2024-01-15T10:00:00Z') or Unix timestamp (e.g. '1705312800'). | |
| instance | No | Target instance name (omit for default instance) |
| Name | Required | Description |
|---|---|---|
| end | Yes | |
| data | Yes | |
| step | Yes | |
| query | Yes | |
| start | Yes | |
| truncated | Yes | |
| result_type | Yes | |
| series_count | Yes | |
| total_points | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it wraps GET /api/v1/query_range, caps total points at 5000 with truncation, notes HTTP 422 rejection for excessive points, and clarifies lack of branch/commit filtering. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose first, then details, examples, and returns. Examples are somewhat lengthy but helpful. Could trim slightly, but overall efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, output schema present), the description covers purpose, usage, behavior, error handling, and return format completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions. The description adds value beyond schema by providing concrete query examples, explaining the step limit in context, and mentioning the truncation hint. Not all parameters get extra context, but the addition is meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Execute a PromQL range query returning time-series data points,' clearly stating the verb and resource. It distinguishes from sibling tools like prometheus_query (single value) and prometheus_list_alerts by providing explicit usage guidance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes dedicated 'Use when' and 'Don't use when' sections with three positive examples and two negative examples referencing sibling tools. This is explicit, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.3alertmanager_get_statusalertmanager_list_alert_groupsalertmanager_list_alertsalertmanager_list_silencescorrelate_alerts_across_instancesdetect_cascading_alertsfederation_list_instancesgroup_alerts_by_serviceprometheus_get_build_infoprometheus_get_cardinalityprometheus_get_metric_metadataprometheus_get_runtime_infoprometheus_health_checkprometheus_list_alerts3 fields changedInput schema / properties / correlation_contextAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Optional correlation context ID from federation_analyze_alerts for enhanced alert analysis.",
+ "title": "Correlation Context"
+}Input schema / properties / include_correlation_infoAdded value: +{
+ "default": false,
+ "description": "Include correlation-relevant information in output.",
+ "title": "Include Correlation Info",
+ "type": "boolean"
+}Input schema / properties / instanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Target instance name (omit for default instance)",
+ "title": "Instance"
+}prometheus_list_label_valuesprometheus_list_metrics1 field changedInput schema / properties / instanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Target instance name (omit for default instance)",
+ "title": "Instance"
+}prometheus_list_rulesprometheus_list_targets1 field changedInput schema / properties / instanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Target instance name (omit for default instance)",
+ "title": "Instance"
+}prometheus_query1 field changedInput schema / properties / instanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Target instance name (omit for default instance)",
+ "title": "Instance"
+}prometheus_query_range1 field changedInput schema / properties / instanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Target instance name (omit for default instance)",
+ "title": "Instance"
+}v0.1.0prometheus_list_alertsprometheus_list_metricsprometheus_list_targetsprometheus_queryprometheus_query_rangeEach tool has a clearly distinct purpose, with detailed descriptions including 'Don't use when' hints to prevent confusion. Overlapping tools like alertmanager_list_alerts and prometheus_list_alerts are well-differentiated by their focus on suppression state versus raw alert state.
All tools follow a consistent verb_noun pattern, prefixed by the subsystem (alertmanager_, prometheus_, correlate_, etc.). Verbs like get, list, query, and health_check are used predictably, making it easy for agents to infer tool function from name.
20 tools cover a comprehensive monitoring domain including Prometheus and Alertmanager queries, status, alerts, targets, metadata, and advanced correlation. The number feels well-scoped without being overwhelming or too sparse.
The tool surface covers most read/analysis operations for Prometheus and Alertmanager, but lacks mutation capabilities like creating silences or updating configurations. For an investigation-focused MCP server, the coverage is strong, but minor gaps prevent a perfect score.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
MCP observability. Query live traffic, errors, duration, and alerts from your AI agent.
Hosted MCP server for live public-data APIs and Skills for AI agents.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mshegolev/prometheus-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
