Which integrations are available for this server?

Provides monitoring for PostgreSQL databases, including checks for liveness, transactions per second (QPS), cache hit ratio, and active connections. Enables monitoring and querying of Prometheus metrics, including system resources, disk usage, network stats, and custom PromQL execution across different environments.

How do I use MCP Prometheus?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Prometheus Show me the average CPU usage for CMS AP #1 in prod over the last 24 hours" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

MCP Prometheus

by yeonkyu-git

Overview Schema Related Servers Score Discussions

Python

Remote

# MCP Prometheus + Loki 📈

Prometheus + Loki 기반 모니터링용 MCP 서버입니다. 엔트리포인트는 main.py입니다.

Quick Start 🚀

cd d:\MCPTools
uv sync
uv run python mcp_prometheus/main.py

Related MCP server: poly-observability-mcp

프로젝트 구조 🧩

mcp_prometheus/
  main.py
  core/
    config.py
    runtime.py
    server.py
    time_utils.py
  domain/
    checks.py
  infra/
    loki_client.py
    prom_client.py
  tools/
    catalog.py
    alerts_runner.py
    checks_runner.py
    loki_query.py
    promql.py
  utils/
    query_utils.py
    summarize.py

Tools 요약 🛠️

Tool	목적	비고
`list_checks`	등록된 체크 목록 조회	`id`, `name`, `description` 반환
`list_environments`	환경별 Prometheus URL 조회	`prod/dev_test/dr`
`list_servers`	최근 up 기준 서버 목록 조회	`(instance, job)` 기준 중복 제거
`list_process_groups`	프로세스 그룹 목록 조회	`process_monitoring` 기준
`list_loki_environments`	환경별 Loki URL 조회	`prod/dev_test`
`list_loki_hosts`	최근 로그 기준 host 후보 조회	기본 최근 1시간
`list_loki_apps`	최근 로그 기준 app 후보 조회	기본 최근 1시간
`find_logs`	구조화된 Loki 로그 조회	`loki_environment`, `log_env`, `host`, `app` 필요
`get_alerts`	Prometheus 활성 Alert 조회	`/api/v1/alerts` 기반, 라벨/상태 필터 지원
`run_check`	단일 체크 실행	기본 권장
`run_all_checks`	전체 체크 병렬 실행	`step=5m` 고정
`run_promql`	사용자 PromQL 직접 실행	`approved=True` 필요

Loki Tool 입력 가이드 🪵

환경 구분

loki_environment: 어떤 Loki 서버로 붙을지 선택 (prod, dev_test)
log_env: Loki 로그 라벨 env 값 (prod, DEV, TEST)

이 둘은 같은 의미가 아닙니다. 예를 들어 dev_test Loki 서버 안에 DEV와 TEST 로그가 함께 있을 수 있으므로, find_logs 호출 시 log_env는 명시적으로 넣어야 합니다.

Discovery Tool

list_loki_hosts
list_loki_apps

공통 규칙:

기본 기간은 최근 1시간
절대 시간 조회 시 start_time_utc_iso, end_time_utc_iso 사용
결과는 중복 제거된 후보 목록 반환

`find_logs`

필수:

loki_environment
log_env
host
app

선택:

기간: hours, minutes, days
절대 시간: start_time_utc_iso, end_time_utc_iso
종료 오프셋: end_offset_minutes, end_offset_hours, end_offset_days
필터: contains, level
개수 제한: limit

응답:

생성된 LogQL
UTC 범위
line_count
logs[] (timestamp, timestamp_jakarta, labels, line)

`run_check` 입력 가이드 🧭

필수

check_id

기간

상대: hours, minutes, days
절대: start_time_utc_iso, end_time_utc_iso
종료 오프셋: end_offset_minutes, end_offset_hours, end_offset_days

타겟 필터

server_name
instance (예: host-or-ip:9100)

필터 규칙:

server_name와 instance를 함께 주면 AND 적용
하나만 주면 해당 라벨만 적용

`run_promql` 가드레일 🔒

approved=False: 실행하지 않고 확인 메시지 반환
approved=True: 실행

모드:

instant=True -> /api/v1/query
instant=False -> /api/v1/query_range

사용 예시 📌

1) 특정 서버 CPU 평균 (최근 24시간)

{
  "check_id": "cpu_avg_pct",
  "hours": 24,
  "instance": "10.23.12.11:9100",
  "environment": "prod"
}

2) 특정 서버 디스크 사용률 (mountpoint별)

{
  "check_id": "disk_used_pct_by_mount",
  "hours": 24,
  "server_name": "CMS AP #1",
  "environment": "prod"
}

3) 사용자 PromQL 실행 (instant)

{
  "promql": "up",
  "approved": true,
  "instant": true,
  "environment": "prod"
}

4) Loki host 후보 조회

{
  "loki_environment": "dev_test",
  "log_env": "DEV",
  "app": "finast",
  "hours": 1
}

5) Loki 로그 조회

{
  "loki_environment": "prod",
  "log_env": "prod",
  "host": "cms-ap-01",
  "app": "cms",
  "hours": 1,
  "contains": "timeout",
  "limit": 200
}

CHECKS Catalog ✅

Source: domain/checks.py (CHECKS)

System / Resource

cpu_avg_pct: CPU average usage (%) by instance/server_name
cpu_peak_pct: window peak CPU usage (%) over selected range
mem_used_pct: memory used ratio (%)
mem_swap_used_pct: swap used ratio (%)
load15_avg: 15-minute load average
cpu_iowait_pct: CPU iowait ratio (%)

Disk / Filesystem

disk_used_pct_by_mount: filesystem used (%) by mountpoint/device (0-100 scale)
disk_used_top5_pct: top 5 filesystem usage (%)
disk_inodes_used_pct: inode usage (%)
fs_readonly: readonly filesystem indicator (1=readonly)
disk_io_busy_pct: disk I/O busy ratio (%)

Availability

up: target liveness (1=up, 0=down)

Process Monitoring

proc_cpu_pct: process group CPU usage (%)
proc_mem_bytes: process group memory usage (bytes)
proc_count: process group process count

PostgreSQL

pg_up: PostgreSQL exporter up state (1=up, 0=down)
pg_qps: PostgreSQL transactions/sec (commit + rollback)
pg_cache_hit_pct: PostgreSQL buffer cache hit ratio (%)
pg_active_conn: active PostgreSQL connections

환경 변수 요약 ⚙️

PROM_ENV_URLS={"prod":"http://...:9090","dev_test":"http://...:9090","dr":"http://...:9090"}
PROM_URL=http://...:9090
PROM_BEARER_TOKEN=
PROM_TIMEOUT_SEC=15

LOKI_ENV_URLS={"prod":"http://...:3100","dev_test":"http://...:3100"}
LOKI_URL=http://...:3100
LOKI_BEARER_TOKEN=
LOKI_TIMEOUT_SEC=15

ALERT_WARN_PCT=85
ALERT_CRIT_PCT=95
ALERT_SUSTAIN_MINUTES=5

PROM_MAX_SAMPLES_PER_SERIES=5000
PROM_MAX_PARALLEL_CHECKS=6

환경 선택 우선순위:

environment
env_hint
PROM_URL fallback

Loki 환경 선택 우선순위:

loki_environment
LOKI_URL fallback

운영 팁 💡

리포트 출력 시 % 단위를 명확히 표기하세요.
단일 서버 점검은 instance 또는 server_name 필터를 사용하세요.
disk_used_pct_by_mount 값은 0~100 스케일입니다. (0.8 = 0.8%)
Loki 조회 전에는 list_loki_hosts 또는 list_loki_apps로 후보값을 먼저 확인하는 편이 안전합니다.

Available Tools

12 tools

find_logsD

ParametersJSON Schema

Name	Required	Description	Default
`loki_environment`	Yes
`log_env`	Yes
`host`	Yes
`app`	Yes
`hours`	No
`minutes`	No
`days`	No
`start_time_utc_iso`	No
`end_time_utc_iso`	No
`end_offset_minutes`	No
`end_offset_hours`	No
`end_offset_days`	No
`limit`	No
`contains`	No
`level`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_alertsC

Fetch active alerts from Prometheus /api/v1/alerts.

Filters (exact-match):

severity/state/alertname/job/server_name/instance

ParametersJSON Schema

Name	Required	Description	Default
`severity`	No
`state`	No
`alertname`	No
`job`	No
`server_name`	No
`instance`	No
`include_alerts`	No
`environment`	No
`env_hint`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Fetch active alerts' and 'Filters (exact-match)', but lacks critical details such as whether this is a read-only operation, potential rate limits, authentication requirements, or what 'active' specifically means (e.g., time-based criteria). This leaves significant gaps for an AI agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the main purpose, followed by a bullet point for filters. It avoids unnecessary words, but the formatting could be slightly improved for clarity (e.g., separating the filter list more distinctly).

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

Completeness3/5

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

Given the tool's moderate complexity (9 parameters, no annotations, but with an output schema), the description is partially complete. It covers the core purpose and some parameters but lacks behavioral details and usage context. The presence of an output schema means return values are documented elsewhere, reducing the burden on the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description lists six filter parameters (severity, state, alertname, job, server_name, instance) and notes they are 'exact-match', adding semantic context beyond the schema's 0% coverage. However, it omits three other parameters (include_alerts, environment, env_hint) and doesn't explain their purposes, leaving some parameters undocumented.

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

Purpose4/5

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

The description clearly states the action ('Fetch active alerts') and the source ('from Prometheus /api/v1/alerts'), making the purpose understandable. However, it doesn't differentiate this tool from sibling tools like 'list_checks' or 'run_promql' that might also relate to monitoring or Prometheus data, which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_checks' or 'run_promql' for comparison, nor does it specify prerequisites, contexts, or exclusions for usage.

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

list_checksB

Return all allowlisted monitoring checks available to the MCP server.

Response:

checks[].id: stable check id
checks[].name: display name
checks[].description: human-readable check description

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states it returns checks but doesn't disclose behavioral traits like whether it's read-only, if it requires authentication, rate limits, or pagination. The response format is described, but this is covered by the output schema, so it adds minimal value beyond structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, stating the core purpose in the first sentence. The response details are included but are necessary for clarity given the lack of annotations, and every sentence earns its place without waste.

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

Completeness3/5

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

Given the tool's simplicity (0 parameters, output schema provided), the description is adequate but has gaps. It explains what is returned, which the output schema covers, but misses behavioral context like safety or usage guidelines, making it minimally viable but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0 parameters and 100% schema description coverage, the baseline is high. The description doesn't need to add parameter details, and it doesn't introduce any confusion, so it meets expectations for a parameterless tool.

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

Purpose4/5

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

The description clearly states the verb ('Return') and resource ('all allowlisted monitoring checks available to the MCP server'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_alerts' or 'run_all_checks', which might have overlapping domains, so it doesn't reach the highest score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on tool names alone, which is insufficient for optimal selection.

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

list_environmentsB

Return configured Prometheus environments and their base URLs.

Response:

environments[].key: environment key (for example prod, dev_test, dr)
environments[].prom_url: Prometheus URL for that environment

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the response format, which adds some value, but fails to cover critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or error handling. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose in the first sentence, followed by a clear breakdown of the response format. Every sentence adds value without redundancy, making it efficient and easy to parse. The structure is logical and concise, with no wasted words.

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

Completeness3/5

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

Given that the tool has 0 parameters, 100% schema coverage, and an output schema exists (implied by the response description), the description is moderately complete. It explains the return values, which compensates for the lack of output schema details. However, without annotations and with no usage guidelines, it falls short of being fully comprehensive for effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters, and the schema description coverage is 100%, so there is no need for parameter explanation in the description. The baseline score for such cases is 4, as the description appropriately avoids redundant information and focuses on other aspects like the response structure.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Return configured Prometheus environments and their base URLs.' It specifies the verb ('Return') and resource ('configured Prometheus environments and their base URLs'), making the function evident. However, it does not explicitly differentiate from sibling tools like 'list_loki_environments', which might cause confusion in usage context.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites, when it should be used over similar tools like 'list_loki_environments' or 'list_servers', and any exclusions or specific scenarios for its application. This absence of usage instructions could lead to incorrect tool selection by an AI agent.

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

list_loki_appsD

ParametersJSON Schema

Name	Required	Description	Default
`loki_environment`	Yes
`log_env`	No
`host`	No
`hours`	No
`minutes`	No
`days`	No
`start_time_utc_iso`	No
`end_time_utc_iso`	No
`end_offset_minutes`	No
`end_offset_hours`	No
`end_offset_days`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_loki_environmentsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_loki_hostsD

ParametersJSON Schema

Name	Required	Description	Default
`loki_environment`	Yes
`log_env`	No
`app`	No
`hours`	No
`minutes`	No
`days`	No
`start_time_utc_iso`	No
`end_time_utc_iso`	No
`end_offset_minutes`	No
`end_offset_hours`	No
`end_offset_days`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

list_process_groupsC

Return process group names from process monitoring metrics.

Source metric:

namedprocess_namegroup_cpu_seconds_total{job="process_monitoring"}
label queried: groupname

ParametersJSON Schema

Name	Required	Description	Default
`environment`	No
`env_hint`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the source metric and label queried, which adds some context about data sourcing. However, it doesn't disclose behavioral traits like whether this is a read-only operation, potential rate limits, authentication needs, or what happens if parameters are omitted. The description is minimal and lacks critical operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise and front-loaded, with the core purpose stated first. Every sentence adds value: the first defines the action, and the second specifies the metric details. There is no wasted text, making it efficient and well-structured.

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

Completeness3/5

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

Given the tool's complexity (listing with parameters) and lack of annotations, the description is incomplete. It covers the data source but omits parameter semantics and behavioral context. However, since an output schema exists, the description doesn't need to explain return values. This partial coverage results in a mediocre score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides no information about the two parameters ('environment' and 'env_hint'), their meanings, or how they affect the query. The description only discusses the metric source, leaving parameters entirely undocumented, which is insufficient given the low coverage.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Return process group names from process monitoring metrics.' It specifies the verb ('return') and resource ('process group names'), and mentions the source metric. However, it doesn't explicitly differentiate this from sibling tools like 'list_checks' or 'list_servers', which also list resources.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this is preferred over other listing tools. The only implicit context is 'process monitoring metrics,' but this lacks explicit usage rules or exclusions.

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

list_serversA

List monitored servers detected from recent up{server_name!=""} series.

Inputs:

environment: explicit environment key (highest priority).
env_hint: fallback environment hint when environment is not provided.

Behavior:

Queries last 10 minutes of up{server_name!=""}.
Returns unique targets by (instance, job) with server_name.

ParametersJSON Schema

Name	Required	Description	Default
`environment`	No
`env_hint`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context beyond the input schema: it specifies the query timeframe ('last 10 minutes'), the PromQL query pattern ('up{server_name!=""}'), and the return format ('unique targets by (instance, job) with server_name'). However, it lacks details on permissions, rate limits, error handling, or whether this is a read-only operation, which is important for a tool querying monitoring data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: the first sentence states the purpose, followed by clear sections for 'Inputs' and 'Behavior.' Every sentence earns its place by adding specific, non-redundant information. There is no wasted text, and it's appropriately sized for a tool with two parameters and specific behavior.

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

Completeness4/5

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

Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is mostly complete. It covers purpose, parameters, and behavior, and the output schema likely handles return values. However, it lacks context on error cases, authentication needs, or how it fits with sibling tools, which would enhance completeness for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the two parameters: 'environment' as 'explicit environment key (highest priority)' and 'env_hint' as 'fallback environment hint when environment is not provided.' This clarifies their roles and priority, adding meaningful semantics beyond the bare schema. However, it doesn't specify what values are valid (e.g., example environments) or how they affect the query, preventing a perfect score.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'List monitored servers detected from recent `up{server_name!=""}` series.' It specifies the verb ('List') and resource ('monitored servers'), and mentions the data source. However, it doesn't explicitly differentiate this from sibling tools like 'list_loki_hosts' or 'list_process_groups', which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_loki_hosts' or 'list_checks', nor does it specify prerequisites, exclusions, or typical scenarios for selecting this tool over others. The behavioral section describes what the tool does, not when to use it.

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

run_all_checksA

Run all allowlisted checks in parallel for the same time range and filters.

Inputs are equivalent to run_check, including:

server_name: filter by label server_name
instance: filter by label instance (single-target filter)

Note:

step is fixed to 5m in this tool to control payload size. Any provided step value is ignored.

ParametersJSON Schema

Name	Required	Default
`hours`	No
`minutes`	No
`days`	No
`step`	No	5m
`include_samples`	No
`start_time_utc_iso`	No
`end_time_utc_iso`	No
`end_offset_minutes`	No
`end_offset_hours`	No
`end_offset_days`	No
`server_name`	No
`instance`	No
`environment`	No
`env_hint`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It effectively describes key behaviors: parallel execution, fixed step parameter ('step is fixed to 5m'), and that provided step values are ignored. It also mentions controlling payload size as rationale. However, it doesn't cover other important behavioral aspects like error handling, performance implications, or what 'allowlisted' means in practice.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely well-structured and concise. The first sentence states the core purpose. The second explains input equivalence to sibling tool. The note section efficiently covers the critical behavioral constraint about the step parameter. Every sentence earns its place with essential information, and the structure is front-loaded with the most important information first.

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

Completeness3/5

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

Given the tool's complexity (14 parameters, parallel execution), no annotations, and 0% schema description coverage, the description does a good job with what it covers but leaves significant gaps. It explains the parallel execution and step constraint well, but doesn't cover most parameters, doesn't explain what 'allowlisted checks' means, and doesn't describe the output format (though an output schema exists, which helps). For a tool with this many parameters and no annotations, more comprehensive coverage would be expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It provides valuable semantic context for 3 parameters: explains that 'server_name' and 'instance' are filter parameters, clarifies that 'step' is fixed at '5m' and any provided value is ignored. However, with 14 total parameters, it only covers 3 of them, leaving 11 parameters without semantic explanation in either schema or description.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'Run all allowlisted checks in parallel for the same time range and filters.' It specifies the action ('run'), scope ('all allowlisted checks'), execution mode ('in parallel'), and constraints ('same time range and filters'). It also distinguishes from sibling 'run_check' by explaining it runs multiple checks instead of one.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool: for running multiple checks in parallel with shared filters. It explicitly references sibling tool 'run_check' and states inputs are equivalent, helping the agent understand the relationship. However, it doesn't specify when NOT to use this tool or mention alternatives beyond the basic comparison to run_check.

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

run_checkA

Run one allowlisted check via Prometheus query_range and return summarized results.

Inputs:

check_id: required check id from domain.checks.CHECKS.
hours/minutes/days: relative lookback window.
start_time_utc_iso/end_time_utc_iso: absolute UTC range (if provided, this is used).
end_offset_minutes/end_offset_hours/end_offset_days: shift end time to the past.
step: range-query step (example: 1m, 5m, 15m).
include_samples: include raw samples in each series summary.
server_name: label filter for server_name.
instance: label filter for instance (example: host-or-ip:9100). Use this when targeting one exact exporter endpoint.
environment/env_hint: environment selector (environment has higher priority).

Filter behavior:

If both server_name and instance are provided, both filters are applied.
If only one is provided, only that label is applied.

ParametersJSON Schema

Name	Required	Default
`check_id`	Yes
`hours`	No
`minutes`	No
`days`	No
`step`	No	5m
`include_samples`	No
`start_time_utc_iso`	No
`end_time_utc_iso`	No
`end_offset_minutes`	No
`end_offset_hours`	No
`end_offset_days`	No
`server_name`	No
`instance`	No
`environment`	No
`env_hint`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses some behavioral traits: it's a read operation (implied by 'return summarized results'), uses Prometheus query_range, and describes filter behavior for server_name/instance. However, it omits critical details like rate limits, authentication needs, error handling, or what 'summarized results' entails structurally.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a purpose statement followed by a bulleted parameter guide and filter behavior explanation. Most sentences earn their place, though some redundancy exists (e.g., listing all time-offset parameters individually). It could be more front-loaded by emphasizing the check_id requirement earlier.

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

Completeness4/5

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

Given the tool's complexity (15 parameters, no annotations) but presence of an output schema, the description is largely complete. It thoroughly documents inputs and basic behavior. The output schema likely covers return values, so the description appropriately focuses on usage semantics. Minor gaps remain in behavioral transparency (e.g., error cases).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It provides detailed semantics for all 15 parameters: explains required vs. optional inputs, gives examples (e.g., step: '1m, 5m, 15m'), clarifies priority rules (absolute vs. relative time, environment vs. env_hint), and documents filter interaction logic. This adds significant value beyond the bare schema.

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

Purpose5/5

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

The description clearly states the tool's purpose with specific verbs ('run', 'return') and resources ('allowlisted check via Prometheus query_range', 'summarized results'). It distinguishes from siblings like 'run_all_checks' (single vs. all checks) and 'run_promql' (predefined checks vs. custom queries).

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

Usage Guidelines3/5

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

The description implies usage context through parameter explanations (e.g., 'when targeting one exact exporter endpoint' for 'instance'), but lacks explicit guidance on when to choose this tool over alternatives like 'run_all_checks' or 'run_promql'. No prerequisites or exclusions are stated.

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

run_promqlA

Run custom PromQL.

Guardrail:

approved must be True before execution.

Modes:

instant=True: use /api/v1/query at a single timestamp.
instant=False: use /api/v1/query_range for a time window.

ParametersJSON Schema

Name	Required	Default
`promql`	Yes
`approved`	No
`instant`	No
`hours`	No
`minutes`	No
`days`	No
`step`	No	5m
`include_samples`	No
`start_time_utc_iso`	No
`end_time_utc_iso`	No
`end_offset_minutes`	No
`end_offset_hours`	No
`end_offset_days`	No
`server_name`	No
`instance`	No
`environment`	No
`env_hint`	No
`alert_pct`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the guardrail requirement and the two execution modes (instant vs. range queries), which helps the agent understand prerequisites and behavioral traits. However, it doesn't cover other important aspects like rate limits, authentication needs, error handling, or what the output looks like (though an output schema exists).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and well-structured with clear sections (Guardrail, Modes). Every sentence earns its place by providing essential information without any fluff or repetition. It's front-loaded with the core purpose and efficiently organized.

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

Completeness3/5

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

Given the high complexity (18 parameters, 0% schema coverage) but with an output schema present, the description is moderately complete. It covers the core purpose, guardrail, and execution modes, which are crucial. However, with so many undocumented parameters and no annotations, it leaves significant gaps in understanding parameter usage and behavioral context beyond what the output schema provides.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate for undocumented parameters. It only explains two parameters ('approved' and 'instant') out of 18 total parameters. While it provides meaningful context for those two, it leaves 16 parameters completely unexplained, failing to adequately compensate for the poor schema coverage.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Run custom PromQL.' This specifies the verb ('Run') and resource ('custom PromQL'), making it immediately understandable. However, it doesn't explicitly differentiate this tool from its siblings (like 'get_alerts' or 'run_check'), which would require a 5.

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

Usage Guidelines4/5

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

The description provides clear usage context with the guardrail ('approved must be True before execution') and explains the two modes based on the 'instant' parameter. This gives practical guidance on when and how to use the tool. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_alerts' or 'run_check' from the sibling list, which would be needed for a 5.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.6/5.0

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness3/5

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.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PGAuditor
com.mcpgatepro
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Databases Monitoring Observability
1
mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247
turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Security Developer Tools
42
AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2

Related MCP Servers

Prometheus MCP Server
Monitoring Databases
CaesarYangs
A
license
Not graded
quality
F
maintenance
An MCP server that enables Large Language Models to retrieve, analyze, and query metric data from Prometheus databases through pre-defined routes.
Updated a year ago (2025-04-05 06:16 UTC)
34
MIT
poly-observability-mcp
Observability Monitoring
hyperpolymath
A
license
Not graded
quality
D
maintenance
Unified MCP server for observability and monitoring, providing tools to query metrics, logs, and traces through Prometheus, Grafana, Loki, and Jaeger.
Updated 2 months ago (2026-07-02 04:27 UTC)
2
Mozilla Public 2.0
mcp-grafana
Monitoring Observability
romaine-life
F
license
Not graded
quality
D
maintenance
In-cluster MCP server for read-only diagnostics of Grafana, Prometheus, Alertmanager, and Loki, enabling metric queries, alert listings, and log queries through Grafana datasource proxies with Kubernetes RBAC authentication.
Updated 3 months ago (2026-06-03 23:52 UTC)
postgres-mcp
Databases Monitoring Developer Tools
Leon-Achteresch
A
license
A
quality
B
maintenance
MCP server for PostgreSQL that enables schema exploration, safe SQL execution, EXPLAIN analysis, health checks, and index recommendations across multiple databases.
Updated a month ago (2026-08-02 12:23 UTC)
10
121
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yeonkyu-git/MCP-Prometheus-Loki'

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

Quick Start 🚀

프로젝트 구조 🧩

Tools 요약 🛠️

Loki Tool 입력 가이드 🪵

환경 구분

Discovery Tool

find_logs

run_check 입력 가이드 🧭

필수

기간

타겟 필터

run_promql 가드레일 🔒

사용 예시 📌

1) 특정 서버 CPU 평균 (최근 24시간)

2) 특정 서버 디스크 사용률 (mountpoint별)

3) 사용자 PromQL 실행 (instant)

4) Loki host 후보 조회

5) Loki 로그 조회

CHECKS Catalog ✅

System / Resource

Disk / Filesystem

Availability

Network / TCP

Process Monitoring

PostgreSQL

환경 변수 요약 ⚙️

운영 팁 💡

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`find_logs`

`run_check` 입력 가이드 🧭

`run_promql` 가드레일 🔒