MCP Prometheus
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROM_URL | No | The default Prometheus server URL used as a fallback. | |
| PROM_ENV_URLS | No | A JSON string mapping environment names (e.g., prod, dev_test, dr) to their respective Prometheus URLs. Example: {"prod":"http://...:9090"} | |
| ALERT_CRIT_PCT | No | The threshold percentage for critical alerts. | 95 |
| ALERT_WARN_PCT | No | The threshold percentage for warning alerts. | 85 |
| PROM_TIMEOUT_SEC | No | Query timeout in seconds for Prometheus requests. | 15 |
| PROM_BEARER_TOKEN | No | Bearer token for Prometheus authentication if required. | |
| ALERT_SUSTAIN_MINUTES | No | The duration in minutes an alert condition must be sustained. | 5 |
| PROM_MAX_PARALLEL_CHECKS | No | The maximum number of checks to run in parallel. | 6 |
| PROM_MAX_SAMPLES_PER_SERIES | No | Maximum number of samples allowed per series for Prometheus queries. | 5000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_checksB | Return all allowlisted monitoring checks available to the MCP server. Response:
|
| list_environmentsB | Return configured Prometheus environments and their base URLs. Response:
|
| list_serversA | List monitored servers detected from recent Inputs:
Behavior:
|
| list_process_groupsC | Return process group names from process monitoring metrics. Source metric:
|
| get_alertsC | Fetch active alerts from Prometheus Filters (exact-match):
|
| run_checkA | Run one allowlisted check via Prometheus Inputs:
Filter behavior:
|
| run_all_checksA | Run all allowlisted checks in parallel for the same time range and filters. Inputs are equivalent to
Note:
|
| list_loki_environmentsD | – |
| list_loki_hostsD | – |
| list_loki_appsD | – |
| find_logsD | – |
| run_promqlA | Run custom PromQL. Guardrail:
Modes:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have distinct purposes, such as get_alerts for fetching alerts and run_check for executing specific checks. However, list_loki_apps, list_loki_environments, and list_loki_hosts are ambiguous without descriptions, potentially causing confusion about their specific functions and differences.
Tool names follow a highly consistent verb_noun pattern throughout, such as list_servers, run_promql, and find_logs. All tools use snake_case without any deviations, making the naming predictable and easy to understand.
With 12 tools, the count is well-suited for a Prometheus monitoring server, covering key operations like listing resources and running queries. It's slightly on the higher side but remains reasonable for the domain, though some tools like the Loki-related ones might be redundant or under-specified.
The toolset provides good coverage for querying and listing operations in Prometheus, including alerts, checks, and servers. However, there are notable gaps, such as missing tools for creating or managing alerts, configuring checks, or handling Loki data beyond listing, which limits full lifecycle management in the monitoring domain.