Skip to main content
Glama
idanfishman

prometheus-mcp

by idanfishman
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

npm Docker codecov Node.js Version License: MIT

A Model Context Protocol (MCP) server that 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 through Visual Studio Code, Cursor, Windsurf, Claude Desktop, and other MCP clients.

Key Features

  • Fast and lightweight. Direct API integration with Prometheus, no complex parsing needed.

  • LLM-friendly. Structured JSON responses optimized for AI assistant consumption.

  • Configurable capabilities. Enable/disable tool categories based on your security and operational requirements.

  • Dual transport support. Works with both stdio and HTTP transports for maximum compatibility.

Related MCP server: Prometheus MCP Server

Requirements

  • Node.js 20.19.0 or newer

  • Access to a Prometheus server

  • VS Code, Cursor, Windsurf, Claude Desktop or any other MCP client

Getting Started

First, install the Prometheus MCP server with your client. A typical configuration looks like this:

{
  "mcpServers": {
    "prometheus": {
      "command": "npx",
      "args": ["prometheus-mcp@latest", "stdio"],
      "env": {
        "PROMETHEUS_URL": "http://localhost:9090"
      }
    }
  }
}
# For VS Code
code --add-mcp '{"name":"prometheus","command":"npx","args":["prometheus-mcp@latest","stdio"],"env":{"PROMETHEUS_URL":"http://localhost:9090"}}'

# For VS Code Insiders
code-insiders --add-mcp '{"name":"prometheus","command":"npx","args":["prometheus-mcp@latest","stdio"],"env":{"PROMETHEUS_URL":"http://localhost:9090"}}'

After installation, the Prometheus MCP server will be available for use with your GitHub Copilot agent in VS Code.

Go to Cursor Settings → MCP → Add new MCP Server. Name to your liking, use command type with the command npx prometheus-mcp. You can also verify config or add command arguments via clicking Edit.

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

Follow Windsurf MCP documentation. Use the following configuration:

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

Claude Desktop supports two installation methods:

Option 1: DXT Extension

The easiest way to install is using the pre-built DXT extension:

  1. Download the latest .dxt file from the releases page

  2. Double-click the downloaded file to install automatically

  3. Configure your Prometheus URL in the extension settings

Option 2: Developer Settings

For advanced users or custom configurations, manually configure the MCP server:

  1. Open Claude Desktop settings

  2. Navigate to the Developer section

  3. Add the following MCP server configuration:

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

Configuration

Prometheus MCP server supports the following arguments. They can be provided in the JSON configuration above, as part of the "args" list:

> npx prometheus-mcp@latest --help

Commands:
  stdio  Start Prometheus MCP server using stdio transport
  http   Start Prometheus MCP server using HTTP transport

Options:
  --help     Show help                          [boolean]
  --version  Show version number                [boolean]

Environment Variables

You can also configure the server using environment variables:

  • PROMETHEUS_URL - Prometheus server URL

  • ENABLE_DISCOVERY_TOOLS - Set to "false" to disable discovery tools (default: true)

  • ENABLE_INFO_TOOLS - Set to "false" to disable info tools (default: true)

  • ENABLE_QUERY_TOOLS - Set to "false" to disable query tools (default: true)

Standalone MCP Server

When running in server environments or when you need HTTP transport, run the MCP server with the http command:

npx prometheus-mcp@latest http --port 3000

And then in your MCP client config, set the url to the HTTP endpoint:

{
  "mcpServers": {
    "prometheus": {
      "command": "npx",
      "args": ["mcp-remote", "http://localhost:3000/mcp"]
    }
  }
}

Docker

Run the Prometheus MCP server using Docker:

{
  "mcpServers": {
    "prometheus": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--init",
        "--pull=always",
        "-e",
        "PROMETHEUS_URL=http://host.docker.internal:9090",
        "ghcr.io/idanfishman/prometheus-mcp",
        "stdio"
      ]
    }
  }
}

Tools

The Prometheus MCP server provides 10 tools organized into three configurable categories:

Tools for exploring your Prometheus infrastructure:

  • prometheus_list_metrics

    • Description: List all available Prometheus metrics

    • Parameters: None

    • Read-only: true

  • prometheus_metric_metadata

    • Description: Get metadata for a specific Prometheus metric

    • Parameters:

      • metric (string): Metric name to get metadata for

    • Read-only: true

  • prometheus_list_labels

    • Description: List all available Prometheus labels

    • Parameters: None

    • Read-only: true

  • prometheus_label_values

    • Description: Get all values for a specific Prometheus label

    • Parameters:

      • label (string): Label name to get values for

    • Read-only: true

  • prometheus_list_targets

    • Description: List all Prometheus scrape targets

    • Parameters: None

    • Read-only: true

  • prometheus_scrape_pool_targets

    • Description: Get targets for a specific scrape pool

    • Parameters:

      • scrapePool (string): Scrape pool name

    • Read-only: true

Tools for accessing Prometheus server information:

  • prometheus_runtime_info

    • Description: Get Prometheus runtime information

    • Parameters: None

    • Read-only: true

  • prometheus_build_info

    • Description: Get Prometheus build information

    • Parameters: None

    • Read-only: true

Tools for executing Prometheus queries:

  • prometheus_query

    • Description: Execute an instant Prometheus query

    • Parameters:

      • query (string): Prometheus query expression

      • time (string, optional): Time parameter for the query (RFC3339 format)

    • Read-only: true

  • prometheus_query_range

    • Description: Execute a Prometheus range query

    • Parameters:

      • query (string): Prometheus query expression

      • start (string): Start timestamp (RFC3339 or unix timestamp)

      • end (string): End timestamp (RFC3339 or unix timestamp)

      • step (string): Query resolution step width

    • Read-only: true

Example Usage

Here are some example interactions you can have with your AI assistant:

Basic Queries

  • "Show me all available metrics in Prometheus"

  • "What's the current CPU usage across all instances?"

  • "Get the memory usage for the last hour"

Discovery and Exploration

  • "List all scrape targets and their status"

  • "What labels are available for the http_requests_total metric?"

  • "Show me all metrics related to 'cpu'"

Advanced Analysis

  • "Compare CPU usage between production and staging environments"

  • "Show me the top 10 services by memory consumption"

  • "What's the error rate trend for the API service over the last 24 hours?"

Security Considerations

  • Network Access: The server requires network access to your Prometheus instance

  • Resource Usage: Range queries can be resource-intensive; monitor your Prometheus server load

Troubleshooting

Connection Issues

  • Verify your Prometheus server is accessible at the configured URL

  • Check firewall settings and network connectivity

  • Ensure Prometheus API is enabled (default on port 9090)

Permission Errors

  • Verify the MCP server has network access to Prometheus

  • Check if authentication is required for your Prometheus setup

Tool Availability

  • If certain tools are missing, check if they've been disabled via configuration

License

This project is licensed under the MIT License - see the LICENSE file for details.

Support

Built with ❤️ for the Prometheus and MCP communities

Available Tools

10 tools
prometheus_build_infoGet Build InfoA
Read-only

Get Prometheus build information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the tool is known to be a safe read operation. The description adds no further behavioral context beyond stating what it does, which is acceptable since annotations carry the safety profile.

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 concise sentence that directly states the tool's purpose without extraneous information. Every word earns its place.

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 zero parameters, no output schema, and clear annotations, the description is sufficiently complete. It provides the essential purpose without needing elaboration on return values or behavior.

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?

There are zero parameters, so the baseline is 4. The description does not need to add parameter meaning beyond the schema, which already fully covers the empty parameter set.

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 uses the specific verb 'Get' and clearly identifies the resource as 'Prometheus build information'. It unambiguously distinguishes this tool from siblings like 'prometheus_query' or 'prometheus_list_targets' which perform different operations.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The usage is implied by the nature of the tool (retrieving build metadata), but no when-not or alternative tool references are given.

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

prometheus_label_valuesGet Label ValuesA
Read-only

Get all values for a specific Prometheus label

ParametersJSON Schema
NameRequiredDescriptionDefault
labelYeslabel name to get values for

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds minimal behavioral context. It does not mention what happens if the label does not exist or if values are sorted.

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 sentence of 9 words, conveying the essential purpose without any redundancy or unnecessary detail.

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?

The tool has no output schema, yet the description does not specify the return format (e.g., array of strings). While simple, this omission could leave the agent uncertain about the response structure.

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 covers the single parameter 'label' with a description, achieving 100% coverage. The description restates the parameter role but does not add extra meaning beyond the 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 verb 'Get' and the resource 'label values', distinguishing it from siblings like prometheus_list_labels which lists labels themselves.

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?

No guidance is provided on when to use this tool versus alternatives, such as prometheus_list_labels for viewing all labels or prometheus_query for more complex data retrieval.

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

prometheus_list_labelsList Prometheus LabelsA
Read-only

List all available Prometheus labels

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating safe read operation. The description adds no further behavioral context beyond this.

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, concise sentence that front-loads the purpose without any wasted words.

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

Completeness5/5

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

Given zero parameters, no output schema, and clear annotations, the description is complete and adequately informs the agent about the tool's functionality.

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 input schema has no parameters (100% coverage), and the description is sufficient for a parameterless tool. Baseline for 0 params is 4.

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 'List all available Prometheus labels' uses a specific verb and resource, clearly distinguishing from sibling tools like prometheus_label_values which lists label values.

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?

No guidance is provided on when to use this tool versus alternatives, nor are there prerequisites or exclusions mentioned.

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

prometheus_list_metricsList Prometheus MetricsA
Read-only

List all available Prometheus metrics

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.8/5.0
Behavior2/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. Description adds no behavioral context (e.g., response format, pagination, potential cost). It does not contradict annotations but provides no extra value.

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?

Single sentence, four words, no redundancy. Perfectly concise for a simple listing tool with no parameters.

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

Completeness5/5

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

Given zero complexity, no parameters, no output schema, and adequate annotations, the description provides complete context. Agent can correctly invoke this tool.

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?

No parameters exist, and schema coverage is 100%. Baseline for zero-parameter tools is 4; here the description is fully adequate as nothing needs explanation.

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?

Description uses specific verb 'List' and resource 'Prometheus metrics', clearly stating what the tool does. It is distinguishable from sibling tools like prometheus_list_labels or prometheus_list_targets by explicitly naming metrics.

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?

No guidance on when to use this tool versus alternatives. Lacks when-to-use, when-not-to-use, or mentions of other list tools. Agent must infer usage from name alone.

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

prometheus_list_targetsList Prometheus TargetsB
Read-only

List all Prometheus targets

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3/5.0
Behavior2/5

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

The description adds no behavioral context beyond what annotations already provide (readOnlyHint, destructiveHint). It merely restates the title, offering no insight into aspects like pagination, filtering, or response format.

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 a single concise sentence. While it is front-loaded, it lacks substantive content beyond the title, making it minimally informative.

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 output schema, the description should explain what 'targets' means and what the response contains. It fails to provide any context about the structure or content of the listing, leaving the agent uninformed.

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?

There are zero parameters, and schema coverage is 100%. The description does not need to explain parameters, but it provides no added value. Baseline of 4 is appropriate.

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 'List all Prometheus targets', which matches the tool's name and purpose. However, it does not differentiate from the sibling tool 'prometheus_scrape_pool_targets', which could lead to confusion about which tool to use for listing targets.

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?

No guidance is provided on when to use this tool versus alternatives like 'prometheus_scrape_pool_targets'. The description lacks context about use cases or exclusions, forcing the agent to infer appropriateness.

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

prometheus_metric_metadataGet Metric MetadataB
Read-only

Get metadata for a specific Prometheus metric

ParametersJSON Schema
NameRequiredDescriptionDefault
metricYesmetric name to get metadata for

TDQS

B3.1/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds no extra behavioral context beyond what annotations provide, such as performance, authentication, or data freshness.

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?

A single, efficient sentence that front-loads the purpose. It is appropriately brief given the tool's simplicity, though it could benefit from slightly more detail without becoming verbose.

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?

The description does not explain what the metadata contains, any limitations, or the return format. As a metadata retrieval tool with no output schema, it lacks completeness.

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

Parameters3/5

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

Schema coverage is 100%, so the parameter 'metric' is documented in the schema. The description indirectly mentions the parameter but adds no additional semantics beyond the 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 verb 'Get' and the resource 'metadata for a specific Prometheus metric'. It distinguishes from sibling tools like prometheus_list_metrics (which lists all metrics) and prometheus_label_values, making it clear this is for a single metric's metadata.

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?

No guidance on when to use this tool versus alternatives like prometheus_list_metrics or prometheus_label_values. The description provides no context for selection.

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

prometheus_queryPrometheus QueryC
Read-only

Execute a Prometheus query

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesprometheus query expression
timeNooptional time parameter for the query, in RFC3339 format

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Execute' implies a safe operation. However, description adds no further behavioral details (e.g., result type, pagination, 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.

Conciseness3/5

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

Single sentence is concise but lacks structure (e.g., no separation of purpose from details). Could be more informative without added length.

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 tool with 2 parameters and no output schema, description fails to mention return format (instant vector vs. matrix) or behavior when time is omitted. Incomplete given complexity.

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 has 100% coverage with descriptions for both parameters (query, time). Description does not add meaning beyond schema, meeting baseline expectation.

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?

States verb and resource ('Execute a Prometheus query') but lacks differentiation from sibling tools like prometheus_query_range, which also executes queries. The verb 'execute' is generic.

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?

No guidance on when to use this tool versus alternatives such as prometheus_query_range. No context on prerequisites or typical use cases.

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

prometheus_query_rangePrometheus Query RangeB
Read-only

Execute a Prometheus range query

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesprometheus query expression
startYesstart timestamp (RFC3339 or unix timestamp)
endYesend timestamp (RFC3339 or unix timestamp)
stepYesquery resolution step width

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no new behavioral context. The description does not contradict annotations, but also fails to explain behaviors like result structure (time-series over range) or potential resource usage.

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 a single sentence, very concise and front-loaded. However, it could be slightly expanded to include key context without losing conciseness.

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 absence of an output schema, the description should clarify return values (time-series data). It does not. Also, with many sibling tools, more context about the purpose of a range query vs instant query would improve completeness.

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 baseline is 3. The description adds no additional meaning beyond what the schema already provides for parameters (query, start, end, step).

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 'Execute a Prometheus range query' clearly specifies the verb 'execute' and the resource 'Prometheus range query'. However, it does not differentiate from sibling tools like 'prometheus_query' (likely an instant query), leaving ambiguity about the distinction between range and instant queries.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of the tool being for time-range queries, nor any exclusions or comparisons to siblings like 'prometheus_query' or 'prometheus_label_values'.

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

prometheus_runtime_infoGet Runtime InfoB
Read-only

Get Prometheus runtime information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds no behavioral details such as what the output looks like, whether it requires authentication, or what happens during execution. With annotations present, the description should add context but does not.

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, concise sentence with no wasted words. It is appropriately structured for a simple tool with no parameters.

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?

While the tool has no parameters and annotations cover safety, the description lacks information about the return value or what 'runtime information' means. Since there is no output schema, the description should fill this gap but does not, leaving the agent uninformed about the tool's output.

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 no parameters, so the input schema fully covers the parameter semantics (100% coverage). The description does not need to add parameter information. Baseline for 0 parameters is 4.

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 'Get Prometheus runtime information' clearly states the action and resource. It is distinct from sibling tools like prometheus_build_info or prometheus_query, which target different specific Prometheus data. However, it is somewhat vague as it does not specify what 'runtime information' encompasses.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives. No context or prerequisites are provided. The single sentence does not help an agent decide whether to use this tool over other querying tools.

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

prometheus_scrape_pool_targetsGet Scrape Pool TargetsA
Read-only

Get targets for a specific scrape pool

ParametersJSON Schema
NameRequiredDescriptionDefault
scrapePoolYesscrape pool name

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds minimal behavioral context beyond the scope (specific pool), which is already implied by the parameter. No additional traits like pagination or limits are disclosed.

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, front-loaded sentence that accurately conveys the tool's purpose with no wasted words.

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?

For a simple read-only tool with one parameter and no output schema, the description is largely sufficient. However, it does not explain what 'targets' are or describe the return format, which could be helpful but is not critical given the low complexity.

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% coverage for the parameter description ('scrape pool name'). The tool description does not add any further meaning about the parameter beyond what the schema already provides, so baseline score of 3 is appropriate.

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 'Get targets for a specific scrape pool' clearly specifies the action (get) and the resource (targets) with a required filter (scrape pool), distinguishing it from sibling tools like prometheus_list_targets which likely lists all targets.

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 when needing targets for a specific scrape pool, but does not explicitly state when to use this tool versus alternatives like prometheus_list_targets, nor does it provide any exclusions or prerequisites.

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.

  1. 5 tool updatesv1.0.0
    • Changedprometheus_build_info1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedprometheus_list_labels1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedprometheus_list_metrics1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedprometheus_list_targets1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedprometheus_runtime_info1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
  2. 10 tool updates
    • First observedprometheus_build_info
    • First observedprometheus_label_values
    • First observedprometheus_list_labels
    • First observedprometheus_list_metrics
    • First observedprometheus_list_targets
    • First observedprometheus_metric_metadata
    • First observedprometheus_query
    • First observedprometheus_query_range
    • First observedprometheus_runtime_info
    • First observedprometheus_scrape_pool_targets
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0
Disambiguation5/5

Every tool has a clearly distinct purpose targeting different aspects of Prometheus monitoring. Tools like prometheus_list_labels, prometheus_list_metrics, and prometheus_list_targets each handle specific listing operations without overlap, while query tools (prometheus_query, prometheus_query_range) are clearly differentiated by scope. There is no ambiguity in tool selection.

Naming Consistency5/5

All tools follow a consistent 'prometheus_verb_noun' pattern with snake_case throughout. The naming convention is perfectly predictable, starting with 'prometheus_' prefix followed by descriptive action and resource pairs (e.g., prometheus_list_metrics, prometheus_query_range). There are no deviations in style or structure.

Tool Count5/5

With 10 tools, this server is well-scoped for Prometheus monitoring operations. Each tool earns its place by covering distinct functionalities like metadata retrieval, listing operations, query execution, and target management. The count is appropriate for the domain without being overwhelming or insufficient.

Completeness4/5

The tool surface provides comprehensive coverage for core Prometheus operations including metadata, listing, querying, and target management. Minor gaps exist, such as the absence of alert management or configuration tools, but agents can work around these with the available query capabilities. The set supports essential monitoring workflows effectively.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Prometheus MCP Server

    yanmxa
    A
    license
    B
    quality
    F
    maintenance
    A Model Context Protocol server that enables AI assistants to query Prometheus metrics, discover available data, and analyze system performance through natural language interactions.
    5
    85
    MIT

  • Prometheus MCP Server

    ArkTechNWA
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to query Prometheus metrics, monitor alerts, and analyze system health through read-only access to your Prometheus server with built-in query safety and optional AI-powered metric analysis.
    MIT

  • Proms MCP Server

    app-sre
    A
    license
    Not graded
    quality
    D
    maintenance
    A lean MCP server that provides LLM agents with transparent access to multiple Prometheus instances for metrics analysis and SRE operations.
    4
    GPL 2.0

  • prometheus-mcp-server

    ramkrsna
    A
    license
    Not graded
    quality
    C
    maintenance
    A Model Context Protocol server that enables AI agents to interact directly with Prometheus metrics data through natural language queries.
    MIT

Appeared in Searches

Latest Blog Posts

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/idanfishman/prometheus-mcp'

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