Which integrations are available for this server?

Provides tools for querying real-time and historical metrics data, discovering available metrics, retrieving metric metadata, and monitoring scrape targets from Prometheus monitoring systems.

How do I use Prometheus MCP Server?

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., "@Prometheus MCP Server show me the current CPU usage across all servers" 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.

Prometheus MCP Server

by yanmxa

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Prometheus MCP Server

npm version License: MIT

A Model Context Protocol (MCP) server that provides seamless integration with Prometheus, enabling AI assistants to query metrics, discover available data, and analyze system performance through natural language interactions.

Features

Real-time Metrics Access - Query current and historical metrics data
Metrics Discovery - Find available metrics and monitoring targets
Multiple Auth Methods - Basic auth, bearer tokens, and TLS support
Type-safe - Full TypeScript implementation

Related MCP server: Prometheus MCP Server

MCP Configuration

Using npx (Recommended)

Add to your MCP client settings:

{
  "mcpServers": {
    "prometheus": {
      "command": "npx",
      "args": ["prometheus-mcp-server"],
      "env": {
        "PROMETHEUS_URL": "http://localhost:9090"
      }
    }
  }
}

Using global installation

First install the package globally:

npm install -g prometheus-mcp-server

Then configure your MCP client:

{
  "mcpServers": {
    "prometheus": {
      "command": "prometheus-mcp-server",
      "env": {
        "PROMETHEUS_URL": "http://localhost:9090"
      }
    }
  }
}

Environment Variables

# Required
PROMETHEUS_URL=http://localhost:9090

# Optional Authentication
PROMETHEUS_USERNAME=admin
PROMETHEUS_PASSWORD=password
PROMETHEUS_TOKEN=bearer-token

# Optional Connection
PROMETHEUS_TIMEOUT=10000
PROMETHEUS_INSECURE=false

Available Tools

Tool	Description	Use Case
`prom_query`	Execute PromQL instant query	Get current metric values, alerts status
`prom_range`	Execute PromQL range query	Analyze trends, create graphs, historical data
`prom_discover`	Discover available metrics	Explore what metrics are available in your system
`prom_metadata`	Get metric metadata	Understand metric types, descriptions, and units
`prom_targets`	Get scrape targets info	Monitor scraping health and service discovery

Example Usage

Ask your AI assistant natural language questions:

"What's the current CPU usage across all servers?"
"Show me HTTP request rates for the last 6 hours"
"Which services have the highest memory consumption?"
"Are there any failing health checks?"
"What metrics are available for monitoring my database?"

Development

# Run with inspector
npm run inspector

# Run directly
npm run dev

Connection Methods

1. No Authentication

export PROMETHEUS_URL=http://localhost:9090

2. Basic Authentication

export PROMETHEUS_URL=http://localhost:9090
export PROMETHEUS_USERNAME=admin
export PROMETHEUS_PASSWORD=secret

3. Bearer Token

export PROMETHEUS_URL=https://prometheus.example.com:9090
export PROMETHEUS_TOKEN=your-bearer-token

Additional Options

For self-signed certificates or development:

export PROMETHEUS_INSECURE=true

License

MIT

Available Tools

5 tools

prom_discoverC

Discover all available metrics

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 for behavioral disclosure. 'Discover all available metrics' implies a read-only operation but doesn't specify whether this returns a complete list, paginated results, cached data, or real-time discovery. It lacks details about performance characteristics, rate limits, or authentication requirements that would help an agent understand how to properly invoke it.

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 perfectly concise at four words. It's front-loaded with the core action ('Discover') and resource ('available metrics'), with zero wasted words. Every element earns its place in this minimal but complete statement of function.

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

Completeness2/5

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

For a tool with no annotations, no output schema, and multiple sibling tools, the description is insufficiently complete. It doesn't explain what 'available metrics' means in context, how results are structured, or how this differs from prom_metadata which might provide similar information. The agent lacks enough context to understand when and how to use this tool effectively.

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 zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing non-existent parameters, though it could theoretically mention if there are implicit filters or scoping considerations not captured in the schema.

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

Purpose3/5

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

The description 'Discover all available metrics' states a clear purpose (discovering metrics) but lacks specificity about what resource or system this applies to. It doesn't differentiate from sibling tools like prom_metadata or prom_query, leaving ambiguity about what distinguishes this discovery operation from those alternatives.

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 its siblings. With tools like prom_metadata, prom_query, prom_range, and prom_targets available, there's no indication whether this is for initial exploration, comprehensive listing, or a specific type of metric discovery. The user must infer usage context from the tool name alone.

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

prom_metadataC

Get metric metadata

ParametersJSON Schema

Name	Required	Description	Default
`metric`	No	Metric name (optional)

TDQS

C2.7/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. 'Get metric metadata' implies a read-only operation, but it doesn't specify whether this requires authentication, has rate limits, returns structured data, or involves any side effects. For a tool with zero annotation coverage, this is a significant gap in transparency.

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 at three words, with no wasted language. It's front-loaded and to the point, making it easy to parse quickly, though this conciseness comes at the cost of detail.

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

Completeness2/5

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

Given no annotations, no output schema, and a simple parameter, the description is incomplete. It doesn't explain what 'metric metadata' entails, how results are returned, or any behavioral traits. For a tool in a set with siblings like prom_query, more context is needed to guide proper use.

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 input schema has 100% description coverage, with the 'metric' parameter documented as 'Metric name (optional)'. The description doesn't add any meaning beyond this, such as examples or format details. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

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

Purpose3/5

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

The description 'Get metric metadata' clearly states the action (get) and resource (metric metadata), which is better than a tautology. However, it doesn't specify what 'metric metadata' includes (labels, types, help text) or differentiate it from sibling tools like prom_discover or prom_query, making it somewhat vague.

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 like prom_discover or prom_query. It lacks any context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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

prom_queryC

Execute a PromQL instant query

ParametersJSON Schema

Name	Required	Description
`query`	Yes	PromQL query expression
`time`	No	Evaluation timestamp (optional)
`includes`	No	Metric properties to include in response (optional)

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 states the action ('Execute') but doesn't describe what happens during execution—whether it's read-only, has side effects, requires authentication, has rate limits, or what the response format looks like. For a query execution tool, this leaves critical behavioral traits unspecified.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no redundant or verbose language.

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

Completeness2/5

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

Given the complexity of executing a PromQL query (which involves query language syntax, evaluation, and potential side effects), the description is incomplete. With no annotations and no output schema, it doesn't explain return values, error handling, or behavioral traits. For a tool with 3 parameters and no structured safety hints, this leaves significant gaps in understanding.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters (query, time, includes) with descriptions. The tool description adds no additional parameter semantics beyond what's in the schema. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't compensate with extra context like examples or constraints.

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 ('Execute') and resource ('PromQL instant query'), making the purpose immediately understandable. It distinguishes from sibling tools like prom_range (which likely handles range queries) and prom_discover/prom_metadata/prom_targets (which are likely for metadata discovery). However, it doesn't explicitly contrast with these siblings, keeping it from 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 like prom_range or prom_discover. It doesn't mention prerequisites, typical use cases, or exclusions. The agent must infer usage from the name and context alone, which is insufficient for optimal tool selection.

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

prom_rangeC

Execute a PromQL range query

ParametersJSON Schema

Name	Required	Description
`query`	Yes	PromQL query expression
`start`	Yes	Start timestamp
`end`	Yes	End timestamp
`step`	Yes	Step interval (e.g., "15s", "1m")
`includes`	No	Metric properties to include in response (optional)

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 full burden for behavioral disclosure but offers minimal information. It states what the tool does but doesn't describe what happens during execution - whether it's read-only, whether it requires authentication, potential rate limits, error conditions, or what the response format looks like. For a query execution tool with zero annotation coverage, this is inadequate.

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 - just four words that directly state the tool's function. There's zero wasted language, and it's front-loaded with the essential information. Every word earns its place.

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

Completeness2/5

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

For a query execution tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a 'range query' means versus other query types, what the tool returns, or any behavioral characteristics. The agent would need to guess about the output format and appropriate usage context.

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

Parameters3/5

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema properties. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

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

Purpose4/5

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

The description clearly states the action ('Execute') and resource ('PromQL range query'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'prom_query' - both appear to execute queries, so the distinction between 'range query' and regular query isn't explained.

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 about when to use this tool versus alternatives. With sibling tools like 'prom_query' and 'prom_discover' available, there's no indication of when a range query is appropriate versus other query types or discovery operations. No prerequisites or exclusions are mentioned.

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

prom_targetsD

Get scrape target information

ParametersJSON Schema

Name	Required	Description	Default
`state`	No

TDQS

D1.8/5.0

Behavior1/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what the tool does ('Get scrape target information') without any details on permissions, rate limits, response format, or side effects. This leaves the agent with insufficient information about how the tool behaves.

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 with a single sentence 'Get scrape target information'. It's front-loaded and wastes no words, though this brevity contributes to its inadequacy in other dimensions.

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?

Given the tool's complexity (inferred from sibling tools suggesting Prometheus monitoring context), no annotations, no output schema, and poor parameter documentation, the description is completely inadequate. It doesn't explain what 'scrape target information' includes, how results are returned, or any operational constraints.

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 input schema has one parameter 'state' with enum values, but schema description coverage is 0%, meaning the schema doesn't explain what 'state' means. The description doesn't mention parameters at all, failing to compensate for the lack of schema documentation. This leaves the agent guessing about parameter usage.

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

Purpose2/5

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

The description 'Get scrape target information' restates the tool name 'prom_targets' in slightly different words, making it tautological. It specifies the verb 'Get' and resource 'scrape target information', but doesn't clarify what 'scrape target information' means or how it differs from sibling tools like prom_discover, prom_query, or prom_range.

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?

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any context, prerequisites, or exclusions, and it doesn't reference sibling tools to help the agent choose appropriately among Prometheus-related functions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesAug 23, 2025
- First observedprom_discover
- First observedprom_metadata
- First observedprom_query
- First observedprom_range
- First observedprom_targets

Install Server

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

TDQS

B3.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: discovery, metadata retrieval, instant queries, range queries, and target monitoring. There is no overlap in functionality, making it easy for an agent to select the right tool for each task without confusion.

Naming Consistency5/5

All tools follow a consistent 'prom_' prefix with descriptive suffixes (discover, metadata, query, range, targets). This uniform naming pattern enhances readability and predictability across the tool set.

Tool Count5/5

With 5 tools, this server is well-scoped for Prometheus monitoring tasks. Each tool serves a specific, essential function in the domain, and the count is neither too sparse nor overwhelming for the intended purpose.

Completeness4/5

The tool set covers core Prometheus operations well, including querying, metadata, and target discovery. A minor gap exists in lacking explicit alert or rule management tools, but agents can still perform most monitoring workflows effectively with the provided tools.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Reddit Discussion

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Foam Observability
io.github.foam-ai
Query application logs, traces, and metrics from your AI coding assistant via Foam's MCP server.
Observability Monitoring Developer Tools
2
Cortex C
io.cortex.mcp
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.
Developer Tools Monitoring Observability
312
Polar SignalsOAuth
com.polarsignals.api
The Polar Signals MCP server enables AI assistants to connect directly with performance profiling data, allowing users to analyze application performance through natural language queries. Key capabilities include querying CPU performance and memory usage, exploring profiling metadata like profile types and labels, and providing AI-driven code optimization suggestions directly within development environments like Claude Code or Cursor.
Monitoring Developer Tools 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
Prometheus MCP Server
Monitoring Observability
pab1it0
A
license
A
quality
A
maintenance
Provides access to Prometheus metrics and queries through standardized Model Context Protocol interfaces, allowing AI assistants to execute PromQL queries and analyze metrics data.
Updated a month ago (2026-08-05 17:30 UTC)
6
513
MIT
Prometheus MCP Server
Monitoring Search
moohoorama
A
license
Not graded
quality
D
maintenance
A tool that enables access to Prometheus metrics data through a Model Context Protocol server, allowing interaction with monitoring data using natural language.
Updated a year ago (2025-05-02 01:46 UTC)
MIT
prometheus-mcp
Monitoring Observability
idanfishman
A
license
A
quality
D
maintenance
Provides seamless integration between AI assistants and Prometheus, enabling natural language interactions with your monitoring infrastructure. This server allows for effortless querying, discovery, and analysis of metrics.
Updated 7 months ago (2026-02-09 01:58 UTC)
10
4,823
27
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/yanmxa/prometheus-mcp-server'

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