Fetches and filters metrics from Amazon EKS clusters via the Kubernetes API server's /metrics endpoint.
Queries Kubernetes API server metrics, including exact metric name and label-based filtering.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@EKS Metrics MCP Server get apiserver_request_total metrics"
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.
Python MCP server for querying Amazon EKS cluster metrics.
Implemented now:
Kubernetes API server /metrics, equivalent to kubectl get --raw /metrics
Metric filtering by exact metric name, metric name regex, and labels
A source selector that currently supports api_server and reserves cloudwatch
CloudWatch metric collection is intentionally left as a future extension.
python3.11 -m pip install -e .The MCP Python SDK requires Python 3.10 or newer. If python points to Python
3.9, use python3.11 or another Python 3.10+ interpreter in both installation
and MCP client configuration.
The server uses the Kubernetes Python client. Authentication follows the same
configuration sources as kubectl:
In-cluster service account credentials when running inside Kubernetes
Local kubeconfig from KUBECONFIG or ~/.kube/config
Optional per-call kube_context and kubeconfig_path tool arguments
The Kubernetes identity must be allowed to call the API server non-resource URL
/metrics.
Related MCP server: MCP Datadog Playcourt
eks-metrics-mcp-serveror:
python3.11 -m eks_metrics_mcp_server.server[mcp_servers.eks-metrics]
enabled = true
command = "python3.11"
args = ["-m", "eks_metrics_mcp_server.server"]
cwd = "/root/eks-metrics-server/eks-metrics-mcp-server"
[mcp_servers.eks-metrics.env]
PYTHONPATH = "/root/eks-metrics-server/eks-metrics-mcp-server/src"get_eks_metricsFetch metrics from the selected source.
Important arguments:
source: api_server or cloudwatch; only api_server is implemented
metric_name: exact Prometheus metric name
metric_name_pattern: regular expression for metric names
label_selectors: label key/value filters
limit: maximum returned samples
include_raw: include original Prometheus sample line
kube_context: kubeconfig context to use
kubeconfig_path: kubeconfig path to use
Example metric names from Kubernetes API server metrics include
apiserver_request_total, apiserver_request_duration_seconds_bucket, and
apiserver_current_inflight_requests.
list_api_server_metric_namesReturn metric names available from /metrics, including type/help metadata and
sample counts.
For an in-cluster deployment, bind a service account to a role that can read
the /metrics non-resource URL:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: eks-metrics-mcp-api-server-metrics
rules:
- nonResourceURLs:
- /metrics
verbs:
- get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-metrics-mcp-api-server-metrics
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: eks-metrics-mcp-api-server-metrics
subjects:
- kind: ServiceAccount
name: eks-metrics-mcp
namespace: defaultFetch EKS metrics from api_server or cloudwatch.
The api_server source calls Kubernetes API server /metrics, equivalent to kubectl get --raw /metrics. CloudWatch is reserved for a future implementation step.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| source | No | api_server | |
| include_raw | No | ||
| metric_name | No | ||
| cluster_name | No | ||
| kube_context | No | ||
| kubeconfig_path | No | ||
| label_selectors | No | ||
| timeout_seconds | No | ||
| metric_name_pattern | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions the equivalent kubectl command for api_server, but does not address authentication requirements, error scenarios, rate limits, or idempotence. The read-only nature is implied but not confirmed, and no safety information is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences and starts with the main action. However, it includes a note about CloudWatch being reserved for future implementation, which is somewhat irrelevant. The structure is adequate but could be more organized by front-loading key usage constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and an output schema, the description is extremely sparse. It does not explain how to connect to a cluster, specify metrics, or interpret results. The sibling tool is not referenced. For a tool with this complexity, the description fails to provide necessary context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 10 parameters with 0% description coverage, and the tool description does not mention any parameter, its purpose, or allowed values. For example, the 'source' parameter defaults to 'api_server', but the description only mentions it in passing. This leaves agents completely uninformed about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches EKS metrics from api_server or cloudwatch, with the api_server source explained. However, it does not differentiate from the sibling tool 'list_api_server_metric_names', which likely serves a complementary purpose. The purpose is clear but lacks explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as the sibling tool 'list_api_server_metric_names'. It only notes that CloudWatch is reserved for future use, implying current limitation. No when-to-use or when-not-to-use instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List metric names exposed by Kubernetes API server /metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| kube_context | No | ||
| kubeconfig_path | No | ||
| timeout_seconds | No | ||
| metric_name_pattern | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that the tool lists metric names, implying a read-only operation, but does not mention any potential side effects, required permissions, or rate limits. The description lacks detail on what happens on errors or timeouts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), but it omits important details. While it avoids verbosity, the brevity sacrifices clarity and completeness, making it less useful than a slightly longer, more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with 0% schema coverage and no annotations, the description is insufficient. It does not mention the output format (though an output schema exists), nor does it provide enough context for an agent to correctly invoke the tool or understand its behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters (kube_context, kubeconfig_path, timeout_seconds, metric_name_pattern). The description does not clarify how these parameters affect the results, leaving the agent to guess their purpose and valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists metric names from the Kubernetes API server /metrics endpoint. However, it does not differentiate from the sibling tool 'get_eks_metrics', which might retrieve actual metric values or focus on EKS-specific metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_eks_metrics'. There is no mention of prerequisites, recommended contexts, or situations where the tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_eks_metricslist_api_server_metric_namesEach tool has a clear, distinct purpose: one fetches actual metrics data, the other lists available metric names. No overlap or ambiguity.
Both tools use consistent snake_case verb_noun pattern: get_eks_metrics and list_api_server_metric_names. Naming is predictable and uniform.
With 2 tools, the server is minimal but well-scoped for its purpose of EKS metrics retrieval. It slightly edges into 'thin' territory but is still reasonable.
Core operations (fetch metrics, list names) are present, but there are notable gaps like filtering, aggregation, or time-range queries. CloudWatch support is missing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides read access to your GKE and Kubernetes resources.
Query PanDev Metrics analytics and reporting data
The Google GKE MCP server is a managed Model Context Protocol server that provides AI applications with tools to manage Google Kubernetes Engine (GKE) clusters and Kubernetes resources. It exposes a structured, discoverable interface that allows AI agents to interact with GKE and Kubernetes APIs, enabling them to inspect cluster configurations, retrieve Kubernetes resource YAMLs, monitor operations like cluster upgrades, diagnose issues, and optimize costs—all without needing to parse text output or use complex kubectl commands.
AWS Cost Explorer cost, forecast, and anomaly reporting through user-connected IAM credentials.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/normalzzz/eks-metrics-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
