Provides diagnostic tools for Kubernetes clusters, including listing nodes, pods, events, and diagnosing crash loops and storage issues.
Provides integration with Red Hat OpenShift clusters, including cluster health assessment, operator status, and SRE analysis with severity classification.
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., "@OpenShift SRE Copilot Check cluster health"
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.
Enterprise-grade AI-powered OpenShift SRE Copilot platform using the Model Context Protocol (MCP).
This platform provides intelligent OpenShift/Kubernetes cluster management through:
MCP Server - Exposes 9 diagnostic tools for LLM integration
Multi-Cluster Support - ARO, ROSA HCP, OSD-GCP, and generic OpenShift/Kubernetes
RAG Knowledge Base - Runbooks, SOPs, and troubleshooting guides
AI SRE Analysis - Intelligent cluster diagnostics with severity classification
Read-Only Security - Safe cluster inspection without modification risk
Autonomous Remediation - AI-powered recommendation engine
Related MCP server: OCP Performance Analyzer MCP
User / LLM (Claude, GPT-4, etc.)
↓
MCP Server (stdio)
↓
9 Diagnostic Tools
↓
Kubernetes API / OpenShift API
↓
Multi-Cluster (ARO, ROSA HCP, etc.)Data Flow:
Cluster → MCP Tools → AI Analysis → RAG Context → RecommendationsNode.js 18+ (Download)
OpenShift CLI (oc) (Installation Guide)
Access to an OpenShift/Kubernetes cluster
npm installOr use the bootstrap script:
bash scripts/bootstrap-enterprise.shCopy the example environment file:
cp .env.example .envEdit .env with your cluster details:
# ARO Cluster Configuration
ARO_CLUSTER_NAME=my-aro-cluster
ARO_API_URL=https://api.aro-cluster.location.aroapp.io:6443
ARO_USERNAME=kubeadmin
ARO_PASSWORD=your-password
# ROSA HCP Cluster Configuration
HCP_CLUSTER_NAME=my-rosa-cluster
HCP_API_URL=https://api.cluster-name.region.openshiftapps.com:443
HCP_USERNAME=admin
HCP_PASSWORD=your-passwordFinding your API URL:
For ARO:
az aro show --name <cluster> --resource-group <rg> --query apiserverProfile.url -o tsvFor ROSA HCP:
rosa describe cluster -c <cluster-name> | grep "API URL"For username/password auth:
oc login <API_URL> -u <username> -p <password> --insecure-skip-tls-verify=trueFor token auth:
oc login --token=<token> --server=<API_URL>npm testExpected output:
✅ Cluster connection successful
✅ Nodes and namespaces listed
✅ RAG system loaded
✅ SRE analysis working
npm startThe server runs in stdio mode and waits for MCP requests.
Tool | Description |
| List all configured clusters |
| Overall cluster health assessment with severity |
| List nodes with status and resource info |
| List pods in a namespace |
| Find pods not in Running/Succeeded state |
| Get recent Kubernetes events |
| Detailed CrashLoopBackOff diagnostics |
| PVC and storage status |
| OpenShift cluster operator status |
Add this to your Claude Desktop config at:~/Library/Application Support/Claude/claude_desktop_config.json (Mac)%APPDATA%\Claude\claude_desktop_config.json (Windows)
{
"mcpServers": {
"openshift-sre": {
"command": "node",
"args": [
"/absolute/path/to/openshift-mcp-sre-tools/src/index.js"
]
}
}
}Restart Claude Desktop, then ask:
"What clusters do I have available?"
"Check the health of my cluster"
"Are there any failing pods?"
"Show me recent events in the openshift-monitoring namespace"
.
├── src/
│ ├── index.js # MCP Server entry point
│ ├── mcp/tools.js # MCP tool definitions
│ ├── openshift/client.js # OpenShift/K8s client wrapper
│ ├── agents/sre-copilot.js # AI SRE analysis engine
│ ├── rag/retriever.js # RAG knowledge retrieval
│ ├── utils/
│ │ ├── logger.js # Winston logging
│ │ └── cluster-config.js # Cluster configuration loader
│ └── test-client.js # Test suite
├── rag/
│ ├── runbooks/ # Operational runbooks
│ ├── sop/ # Standard operating procedures
│ ├── incidents/ # Past incident reports (examples)
│ └── architecture/ # Architecture docs (examples)
├── config/
│ └── clusters.json # Multi-cluster configuration
├── docs/ # Comprehensive documentation
├── scripts/
│ └── bootstrap-enterprise.sh # Setup automation
├── .env.example # Environment template
└── package.json # DependenciesCluster diagnostics with severity classification (healthy/medium/high/critical)
Node health analysis
Storage analysis
Event correlation
Autonomous remediation suggestions
Incident summarization
OpenShift runbooks
Standard Operating Procedures (SOPs)
Incident reports
Troubleshooting guides
Expandable with custom documentation
Read-only mode by default
No cluster modifications without explicit approval
Audit logging
Rate limiting
Credential isolation via .env
Edit config/clusters.json to add/modify clusters:
{
"clusters": [
{
"name": "production-aro",
"type": "ARO",
"apiUrl": "${ARO_API_URL}",
"auth": {
"type": "basic",
"username": "${ARO_USERNAME}",
"password": "${ARO_PASSWORD}"
},
"enabled": true,
"readOnly": true
}
],
"defaultCluster": "production-aro"
}See .env.example for all available configuration options.
Verify API URL is correct (oc cluster-info)
Check credentials in .env
Ensure you've run oc login for basic auth clusters
Test manually: oc get nodes
Token may have expired - re-login with oc login
Check username/password are correct
Verify RBAC permissions (need at least cluster-reader)
User needs read access to cluster resources
Grant cluster-reader role: oc adm policy add-cluster-role-to-user cluster-reader <user>
Verify absolute path in config (no ~ or relative paths)
Restart Claude Desktop completely
Check Claude Desktop logs for errors
Configure credentials in .env
Run oc login before starting the MCP server
The client loads credentials from your ~/.kube/config
Get token from OpenShift Console
Add HCP_TOKEN=sha256~... to .env
Update cluster config to use token auth
Note: The Kubernetes client library doesn't support direct username/password auth. For basic auth, you must run oc login first to create a valid kubeconfig.
SETUP-GUIDE.md - Detailed setup instructions
docs/architecture/ - System architecture
docs/setup/ - Getting started guides
docs/troubleshooting/ - Common issues
rag/runbooks/ - Operational runbooks
npm testnpm run devnpm run bootstrap✅ ROSA HCP - Red Hat OpenShift Service on AWS (Hosted Control Plane)
✅ ARO - Azure Red Hat OpenShift
✅ OSD-GCP - OpenShift Dedicated on Google Cloud
✅ Generic OpenShift - Self-managed OpenShift
✅ Kubernetes - Generic Kubernetes clusters
🔒 READ_ONLY_MODE is enabled by default - no modifications to cluster state
Never commit:
.env file (contains credentials)
kubeconfig files
API keys or tokens
The .gitignore is configured to protect sensitive files.
Loki integration for log analysis
Prometheus/Grafana dashboards
Slack/Teams bot integration
Fine-tuned SRE LLM model
n8n workflow automation
Multi-cluster federation support
MIT
Check logs in logs/combined.log and logs/error.log
Review cluster configuration in config/clusters.json
See runbooks in rag/runbooks/ for common issues
Built with:
@modelcontextprotocol/sdk - MCP protocol
@kubernetes/client-node - Kubernetes API
Winston - Logging
ChromaDB - RAG vector storage (optional)
Diagnose a pod in CrashLoopBackOff state and provide remediation suggestions
| Name | Required | Description | Default |
|---|---|---|---|
| cluster | No | Cluster name | |
| podName | Yes | Pod name | |
| namespace | Yes | Kubernetes namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It says 'diagnose' and 'provide remediation suggestions' but does not disclose what actions are taken (e.g., fetching logs, checking events). Behavior is vague.
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?
Single sentence, clear and concise. Could be improved by front-loading the action and adding structure, but no wasted words.
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?
With no output schema and no behavioral details, the description is incomplete for a diagnostic tool. It doesn't explain what the output looks like or what 'remediation suggestions' entails, leaving the agent underinformed.
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?
All three parameters have descriptions in the schema (100% coverage), so baseline is 3. The description does not add extra meaning beyond the schema; it only contextualizes the tool's purpose.
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 diagnoses a pod in CrashLoopBackOff state and provides remediation suggestions. It specifies the exact problem state and action, distinguishing it from siblings like get_pods (lists pods) or get_failing_pods (lists failing pods).
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?
Implied usage: when a pod is in CrashLoopBackOff. But no explicit when-not-to-use or alternatives. For example, if only pod status is needed, get_pods might suffice. Lacks guidance compared to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get overall health status of an OpenShift cluster including nodes, operators, and critical workloads
| Name | Required | Description | Default |
|---|---|---|---|
| cluster | No | Cluster name (optional, uses default if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It correctly implies a read-only operation via 'get' and specifies covered entities (nodes, operators, workloads). Lacks explicit mention of safety or side effects, but sufficient for a health check.
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?
Single sentence that is front-loaded with the action and resource. Every word contributes value; no redundancy.
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?
Description covers the tool's purpose but lacks details on return value format or structure. With no output schema, the description could be more complete to fully inform the agent.
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 coverage is 100% for the single parameter 'cluster' with a clear description. Tool description adds no extra meaning beyond the schema, so baseline 3 applies.
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?
Clearly states verb 'Get', resource 'overall health status of an OpenShift cluster', and scope including nodes, operators, and critical workloads. Distinguishes from siblings that focus on specific aspects like nodes or operators.
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?
Implicitly suggests usage for high-level health overview, but no explicit guidance on when to use this tool versus sibling tools like get_nodes or get_cluster_operators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status of OpenShift cluster operators
| Name | Required | Description | Default |
|---|---|---|---|
| cluster | No | Cluster name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral details such as read-only nature, authentication requirements, or error handling. The agent has no insight beyond the basic action.
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 extremely concise at one sentence, with no wasted words. However, it lacks structure such as sections or bullet points, which would improve readability for complex tools.
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?
Without an output schema, the description should explain what 'status' includes or what the response looks like. It fails to provide enough context for an agent to understand the tool's output or 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?
Schema coverage is 100% with one parameter described in the schema. The description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.
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 specifies the verb 'Get' and the resource 'status of OpenShift cluster operators', clearly indicating the tool's function. However, it does not differentiate from sibling tools like 'get_cluster_health', which might also relate to operator status.
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, nor does it mention prerequisites or limitations. It is a single sentence without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent Kubernetes events for troubleshooting
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of events to return | |
| cluster | No | Cluster name | |
| namespace | Yes | Kubernetes namespace | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a safe, read-only operation ('Get recent events'), but does not explicitly confirm non-destructiveness, auth needs, or rate limits. Adequate for a simple read, but lacks detail.
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?
Single sentence is concise and front-loaded with the core purpose. However, the brevity leaves some gaps, but the sentence earns its place.
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?
No output schema exists, and the description does not explain return values (e.g., event fields). However, the tool is simple with well-documented parameters, and the context 'for troubleshooting' implies typical event fields. Adequate but could be more complete.
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?
Input schema provides 100% parameter coverage with descriptions, so baseline is 3. The description adds no extra parameter context beyond the schema.
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 retrieves recent Kubernetes events for troubleshooting, which is a specific verb+resource. It distinguishes from sibling tools that focus on cluster health, pods, or crash loops, though 'recent' is somewhat vague.
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_pods or diagnose_crashloop. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get pods that are not in Running state (CrashLoopBackOff, Error, Pending, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| cluster | No | Cluster name | |
| namespace | No | Kubernetes namespace (optional, checks all if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the filtering behavior (non-Running states) but does not mention authentication, result limits, or return format. Adequate for a simple read tool but lacks depth.
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 one concise sentence with no extraneous information. It front-loads the core purpose and fits the context.
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's simplicity (2 params, no output schema), the description is fairly complete. It explains what it returns and the filtering condition. However, it could mention the return format (e.g., pod names or details) but overall adequate.
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 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what is in the schema, thus baseline score of 3.
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 verb 'Get' and the resource 'pods that are not in Running state', with explicit examples of failing states. This distinguishes it from sibling tools like get_pods (all pods) and diagnose_crashloop (diagnostic).
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 implies usage for filtering failing pods but does not explicitly state when to use vs alternatives like get_pods or diagnose_crashloop. No when-not or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all nodes in the cluster with status and resource information
| Name | Required | Description | Default |
|---|---|---|---|
| cluster | No | Cluster name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only implies a read operation but doesn't disclose side effects, authentication needs, or behavior beyond listing.
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?
Single sentence with no wasted words, front-loaded with verb and resource.
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?
Adequate for a simple list tool; describes output as 'status and resource information' but no output schema. Additional detail on returned fields would improve completeness.
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 coverage is 100% with a single parameter 'cluster' described as 'Cluster name'. Description adds no extra meaning beyond the schema, achieving baseline for high coverage.
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 'List all nodes in the cluster with status and resource information', specifying verb, resource, and scope. However, it does not differentiate from sibling tools like get_cluster_health.
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 vs alternatives such as get_cluster_health or get_pods. Lacks context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pods in a namespace with their status
| Name | Required | Description | Default |
|---|---|---|---|
| cluster | No | Cluster name | |
| namespace | Yes | Kubernetes namespace (default: all namespaces) | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description implies a read-only operation by stating 'List', but it does not disclose any behavioral traits such as pagination, result limits, or the exact structure of 'status' information. The description is minimal but sufficient for a simple list tool.
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 a single, clear sentence that is well front-loaded. It could be slightly improved by adding brief usage context without becoming verbose.
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's simplicity and lack of output schema, the description adequately states the basic functionality. However, it does not explain the return format or how the status information is presented, which would help an agent interpret results. Sibling tools are not differentiated.
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?
Although schema descriptions cover both parameters at 100%, the description does not add new semantic value. It mentions 'in a namespace' but the schema's default value and property description are inconsistent (required namespace with default 'default' but description says 'all namespaces'), which the description fails to clarify.
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 action ('List'), resource ('pods'), and context ('in a namespace with their status'), making it easy to understand the tool's purpose. However, it does not explicitly differentiate from sibling tools like get_failing_pods, which could cause confusion.
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 is provided on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or scenarios where other tools like get_failing_pods would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get storage information including PVCs and their status
| Name | Required | Description | Default |
|---|---|---|---|
| cluster | No | Cluster name | |
| namespace | No | Kubernetes namespace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It implies a read-only operation via 'Get', but does not disclose potential side effects, latency, or authentication needs. The description is insufficient for an agent to understand the tool's behavioral profile.
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, consisting of a single sentence that is front-loaded with the main action. It achieves efficiency without unnecessary words, though it could be slightly more informative without harming conciseness.
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 no output schema, the description provides a hint about the output (PVCs and their status) but lacks details on whether other storage objects are included, pagination, or error scenarios. It is adequate for a simple tool but leaves gaps for an AI agent to infer.
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 coverage is 100% with descriptions for both parameters ('Cluster name' and 'Kubernetes namespace'). The description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
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 it gets storage information including PVCs and their status. It distinguishes from sibling tools which cover other cluster aspects like health, operators, pods, etc. However, it could be more specific about what 'storage information' includes (e.g., persistent volumes, storage classes) beyond just PVCs.
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. While sibling tools have different purposes, the description does not provide any context on prerequisites, such as required permissions or when to use this tool for storage-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available OpenShift clusters
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states 'list' which implies a read-only operation with no side effects, but does not disclose any behavioral traits such as authentication needs, rate limits, or response format. Adequate for a simple list tool but lacks depth.
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?
Single sentence that is front-loaded with the action and resource. Every word is necessary, no filler or repetition.
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?
For a simple list operation with no parameters and no output schema, the description is complete. It conveys the essential functionality without requiring additional context.
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?
No parameters exist in the schema, so baseline is 4. Description adds no additional parameter information beyond the schema, which is expected for a parameterless tool.
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 states 'List all available OpenShift clusters' with a specific verb (list) and resource (clusters). It clearly distinguishes from sibling tools that focus on health, operators, pods, etc., which are more specific.
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 explicit guidance on when or when not to use this tool. It is implied that it should be used to get a list of clusters before using more specific tools, but no alternatives or prerequisites are mentioned.
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.
v1.0.0diagnose_crashloopget_cluster_healthget_cluster_operatorsget_eventsget_failing_podsget_nodesget_podsget_storage_infolist_clustersTools have distinct purposes, with slight overlap between get_pods and get_failing_pods, but descriptions clearly differentiate them. Others like diagnose_crashloop and get_cluster_health are distinct.
All tools follow a consistent verb_noun pattern (diagnose_, get_, list_), with clear and predictable naming.
With 9 tools, the set is well-scoped for an SRE diagnosis and monitoring tool, covering essential operations without bloat.
Covers key diagnosis tasks (health, pods, nodes, events, storage, crash loops). Missing log retrieval or resource updates, but fits a focused diagnostic scope.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered incident management and server monitoring via MCP.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP-native AI SRE: ask what's broken in production, get a reviewed GitHub fix PR.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/agentic-devops/mcp-sre-tools'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
