This server provides a unified MCP interface for real-time management and querying of DevOps and infrastructure components, enabling AI agents to debug incidents, monitor system health, and automate operations securely.
Kubernetes (k8s__*) – Full cluster management including pod inspection, logs, resource scaling, deployments, rolling restarts, manifest apply with dry-run, delete with confirmation, events, node status, HPA, services, ingresses, network policies, PVCs, CronJobs, drift detection, and context/usage views.
ArgoCD (argo__*) – Monitor and manage apps: sync, rollback, history, resource tree, live diff.
Prometheus (prom__*) – Execute PromQL queries (instant/range), check alerts, targets, label values, SLO compliance, and service health summaries.
Loki (logs__*) – Search logs for error analysis and root cause investigation.
PagerDuty (pd__*) – Manage incidents (acknowledge, escalate, add notes, summaries), on-call info, and audit logs.
Helm (helm__*) – Release management: list, status, values, rollback.
Cross-provider debugging (devops__*) – Aggregated diagnostics via debug_service, explain_change, runbook, health_report, and incident_timeline to correlate data from all tools.
Mutations are safeguarded by dry-run previews and confirmation flags.
Provides tools for querying and managing ArgoCD applications, including listing apps, viewing sync status, performing syncs, rollbacks, and diffs between git and cluster state.
Provides tools for managing Helm charts and releases, allowing AI agents to interact with Helm via CLI from within the MCP server.
Provides tools for querying and managing Kubernetes resources, including pods, deployments, services, events, logs, and cluster configuration, with read, mutate, and destructive tiers.
Provides tools for querying PagerDuty incident data and on-call schedules, enabling AI agents to check who is on call and what incidents are open.
Provides tools for querying Prometheus metrics via PromQL, listing alerts, targets, and generating human-readable service health summaries including latency, error rates, and SLO status.
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., "@devops-mcp Why is payments deployment in CrashLoopBackOff?"
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.
Unified MCP server for DevOps engineers — query and manage Kubernetes, ArgoCD, Prometheus, and PagerDuty from any MCP-compatible AI agent.
devops-mcp is an open source Model Context Protocol server that gives AI agents (Claude, etc.) real-time read and write access to your infrastructure stack — all from a single install.
Instead of copy-pasting kubectl output into a chat window, you can ask:
"Why is the payments deployment in CrashLoopBackOff?" "What changed in the last ArgoCD sync for the auth app?" "Show me the p99 latency for the API gateway over the last hour." "Who's on call right now and what incidents are open?" "Debug the payments service - what's wrong with it?"
...and get live answers, sourced directly from your cluster and tooling.
Providers included:
Prefix | Provider | Transport |
| Kubernetes (via kubeconfig or in-cluster SA) | client-go |
| ArgoCD | REST API |
| Prometheus | HTTP API (PromQL) |
| PagerDuty | REST API v2 |
| Helm | CLI (helm binary) |
| Cross-provider incident debugging | Aggregates all providers |
| Loki | HTTP API (LogQL) |
Related MCP server: LUMINO MCP Server
Add this to ~/.config/claude/claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"devops": {
"command": "npx",
"args": ["-y", "@notharshhaa/devops-mcp@latest"],
"env": {
"KUBECONFIG": "/home/you/.kube/config",
"ARGOCD_SERVER": "https://argocd.company.com",
"ARGOCD_TOKEN": "your-argocd-token",
"PROMETHEUS_URL": "http://prometheus.monitoring:9090",
"PAGERDUTY_TOKEN": "your-pd-api-token",
"LOKI_URL": "http://loki.monitoring:3100",
"LOKI_TOKEN": "your-loki-token"
}
}
}
}Restart Claude Desktop. The devops server will appear in the tools list.
claude mcp add devops-mcp -e KUBECONFIG=$HOME/.kube/config \
-e ARGOCD_SERVER=https://argocd.company.com \
-e ARGOCD_TOKEN=... \
-e PROMETHEUS_URL=http://prometheus:9090 \
-e PAGERDUTY_TOKEN=... \
-e LOKI_URL=http://loki.monitoring:3100 \
-e LOKI_TOKEN=... \
-- npx -y @notharshhaa/devops-mcp@latestRequires Node.js 20 or newer.
npx @notharshhaa/devops-mcp
# or clone and run:
git clone https://github.com/NotHarshhaa/devops-mcp
cd devops-mcp
npm install
cp .env.example .env # fill in your values
npm run devAll config is via environment variables. Only set the ones for providers you actually use — providers with missing config are silently skipped.
# ── Kubernetes ────────────────────────────────────────────────
KUBECONFIG=/home/user/.kube/config # omit to use in-cluster service account
K8S_CONTEXT=my-prod-context # optional: pin a specific context
K8S_ALLOWED_NAMESPACES=default,backend # optional: restrict namespace access
# ── ArgoCD ───────────────────────────────────────────────────
ARGOCD_SERVER=https://argocd.company.com
ARGOCD_TOKEN=eyJhbGci... # argocd account generate-token
# ── Prometheus ───────────────────────────────────────────────
PROMETHEUS_URL=http://prometheus:9090
PROMETHEUS_BEARER_TOKEN= # optional: for authenticated Prometheus
# ── PagerDuty ────────────────────────────────────────────────
PAGERDUTY_TOKEN=your-api-v2-token
# ── Loki ───────────────────────────────────────────────────
LOKI_URL=http://loki.monitoring:3100
LOKI_TOKEN=your-loki-token
# ── Stateless Streamable HTTP ────────────────────────────────
# For stdio mode (default): no transport config needed
MCP_HTTP_HOST=127.0.0.1 # use 0.0.0.0 inside a container
PORT=3000
MCP_AUTH_TOKEN=shared-secret # optional static Bearer token
MCP_REQUEST_STATE_SECRET=32+-byte-secret # optional MRTR signing key shared by all replicas
MCP_ALLOWED_HOSTS=localhost,127.0.0.1 # required with non-loopback binding
MCP_ALLOWED_ORIGINS= # optional browser Origin hostname allowlist
MCP_CACHE_TTL_MS=60000 # discovery/tools catalog TTL; 0 disables caching
# ── Safety ───────────────────────────────────────────────────
DEVOPS_MCP_DRY_RUN=false # true = block all mutations globally
DEVOPS_MCP_AUDIT_LOG=/var/log/devops-mcp-audit.jsonlAll tools follow a three-tier safety model:
Read — safe, no side effects, no confirmation needed
Mutate — defaults to dry_run: true; set dry_run: false to execute
Destructive — requires confirm: true, or a 2026-07-28 client can complete the server's interactive MRTR confirmation
k8s__*)Tool | Tier | Description |
| read | List pods with status, restarts, node, age |
| read | Tail or stream logs from a pod container |
| read | Full describe for any resource type |
| read | Cluster or namespace events, filterable by reason |
| read | Deployments with replica counts and rollout health |
| read | CPU/mem usage per pod via metrics-server |
| read | Node health, conditions, capacity, allocatable resources, taints |
| read | Network policies with pod selectors and ingress/egress rules |
| read | Ingress resources with hosts, paths, backends, TLS config |
| read | CronJobs with schedule, last run, active jobs, suspend status |
| read | Detailed CronJob status with recent job history |
| read | Compare current resource state vs last-applied-configuration |
| read | HorizontalPodAutoscaler with current/target metrics and scaling status |
| read | PersistentVolumeClaims with status, capacity, storage class |
| read | Services with type, ports, selectors, clusterIP, endpoints |
| read | All kubeconfig contexts and the active one |
| mutate | Preview a context selection; set |
| mutate | Scale replicas with dry-run diff preview |
| mutate | Apply a manifest string with server-side dry-run |
| mutate | Trigger rolling restart of a deployment or statefulset |
| destructive | Delete a named resource — requires direct or interactive confirmation |
argo__*)Tool | Tier | Description |
| read | All apps with health, sync status, source repo |
| read | Full spec and status for one application |
| read | Live diff between git and cluster state |
| read | Deployment history with git SHAs and timestamps |
| read | Full owned resource tree for an app |
| mutate | Trigger sync — supports dry-run, prune, force |
| mutate | Preview rollback to a history revision; set |
| mutate | Preview cancellation of an in-progress sync; set |
prom__*)Tool | Tier | Description |
| read | Instant PromQL query with label + value output |
| read | Range query with step, returns time-series data |
| read | All alert rules with state (firing / pending / inactive) |
| read | Only currently firing alerts with duration |
| read | All scrape targets with health and last scrape |
| read | Enumerate values for a given label name |
| read | Type, help text, and unit for a metric |
| read | 📈 Compare metrics between two time windows — detect before/after deployment changes |
| read | 🎯 SLO compliance — error budget remaining, burn rate, time to exhaustion |
| read | 📊 Smart summary - human-readable service health metrics including latency changes, error rate vs SLO, and traffic patterns |
Example usage:
# Get a human-readable health summary
prom__summarize_service_health(service="payments", timeframeMinutes=30, sloThreshold=0.05)What it outputs:
Latency: "Latency increased: 120ms → 480ms (+300%)" or "Latency stable: 125ms"
Error rate: "Error rate crossed SLO (5%): 7.2%" or "Error rate within SLO: 2.1%"
Traffic: "Traffic dropped: 500 → 350 req/s (-30%)" or "Traffic spike detected (+150%)"
Overall assessment: Summary of issues and positive indicators
Why this matters: Instead of raw PromQL numbers that require interpretation, this tool provides actionable insights that AI agents can use directly in responses, making monitoring data actually useful for incident investigation and communication.
logs__*)Tool | Tier | Description |
| read | Get recent error logs from Loki for debugging incidents |
| read | Search logs in Loki with custom query for root cause analysis |
Example usage:
# Get recent error logs
logs__get_recent_errors(service="payments", namespace="default", minutes=30, limit=50)
# Search logs with custom query
logs__search(query='{service="payments"} |= level="error"', limit=100)Why this matters:
Metrics tell what: Prometheus shows you that latency increased or error rate crossed SLO
Logs tell why: Loki shows you the actual error messages, stack traces, and context around failures
Complete debugging: Without logs, you can see that something is broken but not understand the root cause
Output format:
Structured log entries with timestamp, message, service, namespace, and extracted log levels
Error count summaries and filtering
Raw LogQL results for detailed analysis
This makes incident investigation complete by combining the "what" (metrics) with the "why" (logs).
pd__*)Tool | Tier | Description |
| read | Open incidents with severity, status, assignee |
| read | Full detail with alerts, notes, timeline |
| read | Current on-call per schedule or escalation policy |
| read | All services with integration keys and status |
| read | Audit log for an incident (all state changes) |
| mutate | Preview acknowledgement; set |
| mutate | Preview appending a note; set |
| destructive | Escalate to a different policy — requires direct or interactive confirmation |
| read | 🚨 Incident auto-summary - what happened, affected services, probable root cause, current status |
pd__summarize_incidentExample usage:
# Get an auto-summary of an incident
pd__summarize_incident(id="ABC123")What it outputs:
What happened: Incident title, description, severity, urgency, status, creation time, and duration
Affected services: Service name, ID, and current status
Probable root cause: Analysis of trigger alerts and log entries to identify likely causes
Current status: Current incident state, assignees, acknowledgements, and notes count
Output format:
{
"what_happened": {
"title": "API Gateway High Error Rate",
"description": "5xx error rate exceeded 5% threshold",
"severity": "high",
"urgency": "high",
"status": "acknowledged",
"createdAt": "2025-01-15T10:30:00Z",
"updatedAt": "2025-01-15T11:45:00Z",
"duration": "1h 15m"
},
"affected_services": [
{
"id": "P123456",
"name": "API Gateway",
"status": "critical"
}
],
"probable_root_cause": "Triggered by: High 5xx error rate from API Gateway pods",
"current_status": {
"status": "acknowledged",
"lastUpdated": "2025-01-15T11:45:00Z",
"assignees": ["john.doe@company.com"],
"acknowledgements": 2,
"notes": 3
}
}Why this matters: Instead of manually piecing together incident details from multiple API calls, this tool provides a comprehensive, human-readable summary perfect for:
Demos: Shows AI's ability to understand and summarize complex incident data
Real-world use: Quickly understand incident impact without digging through raw data
Communication: Share concise incident summaries with stakeholders
helm__*)Tool | Tier | Description |
| read | List Helm releases with status, chart, app version |
| read | Full status of a Helm release |
| read | User-supplied or computed values for a release |
| read | Revision history of a release |
| mutate | Rollback to a previous revision (dry-run by default) |
Requirements: Helm CLI binary must be available in PATH.
Example usage:
# List all releases in a namespace
helm__list_releases(namespace="production")
# Check what values a release is using
helm__get_values(name="api-gateway", all_values=true)
# Rollback after a bad deploy
helm__rollback(name="api-gateway", revision=5, dry_run=false)devops__*)Tool | Tier | Description |
| read | 🔥 Cross-provider incident debugging - aggregates Kubernetes, ArgoCD, Prometheus, and PagerDuty data to diagnose service issues in one command |
| read | 🧠 Explain what changed - combines ArgoCD history, Kubernetes rollout history, and Prometheus anomaly window to identify cause of issues |
| read | 📋 Automated runbook - symptom-based diagnostic that runs targeted checks (crashloop, high-latency, oom, 5xx, pod-pending) |
| read | 🏥 Cluster health report - one-shot assessment across all providers with overall status (healthy/degraded/critical) |
| read | 🕐 Incident timeline - unified event timeline across K8s, ArgoCD, Prometheus, and PagerDuty sorted chronologically |
devops__debug_serviceExample usage:
# Debug a service across all providers
devops__debug_service(service="payments", namespace="default")What it checks:
Kubernetes: Pod status, restart counts, readiness, deployment health, recent events
ArgoCD: Sync status, health status, Git diff detection, deployment history
Prometheus: Error rate (5xx responses), latency (p95), firing alerts
PagerDuty: Active incidents matching the service name
Output format:
Human-readable diagnosis with emoji indicators (⚠️ warnings, ❌ errors)
Per-provider status sections
Summary highlighting critical issues
Raw JSON data for detailed analysis
This is the most powerful tool for incident investigation - it gives you a complete picture of what's wrong with a service in seconds.
devops__explain_changeExample usage:
# Explain what changed in the last hour
devops__explain_change(service="payments", namespace="default", timeframeMinutes=60)What it analyzes:
ArgoCD: Deployment history within the timeframe, including revision, author, repo, and chart
Kubernetes: Current rollout status, replica counts, image tags, and deployment readiness
Prometheus: Error rate trends, latency patterns, and traffic spikes over the time window
Output format:
Timeline of recent deployments with full metadata
Kubernetes rollout status and health
Metric anomaly detection (error rate spikes, latency issues, traffic changes)
Correlation analysis that links deployments to metric changes
Summary with root cause hypothesis
Problem it solves: "Everything was working yesterday… what changed?"
This tool answers that question by correlating deployment events with metric anomalies, helping you quickly identify whether a recent deployment, config change, or external factor caused the issue.
devops__runbookExample usage:
# Diagnose a crashlooping service
devops__runbook(symptom="crashloop", service="payments", namespace="default")
# Investigate high latency
devops__runbook(symptom="high-latency", service="api-gateway")Supported symptoms:
Symptom | What it checks |
| Pod status → logs (tail 50) → BackOff events → deployment health |
| p95 latency → resource usage → firing alerts → recent deploys |
| OOMKilled events → memory usage → pod describe → resource limits |
| Error rate → Loki error logs → deployment health |
| Scheduling events → pending pods → node capacity |
Output: Structured JSON with steps_executed[], findings[], and recommended_actions[].
devops__health_reportExample usage:
# Get a full cluster health assessment
devops__health_report(namespace="production")What it gathers:
Kubernetes: Unhealthy pods, deployments not at desired replicas
Prometheus: Count of firing alerts
ArgoCD: Out-of-sync and unhealthy applications
PagerDuty: Open incident count
Output: Overall status (healthy / degraded / critical), per-provider sections, and summary. Perfect for morning standup checks or shift handoffs.
The MCP host launches devops-mcp as a subprocess and communicates over stdin/stdout. Zero network config. Auth comes from the local environment (kubeconfig, env vars). Process lifecycle tied to Claude Desktop.
npx @notharshhaa/devops-mcp
# or with env vars
KUBECONFIG=~/.kube/config npx @notharshhaa/devops-mcpThe HTTP entry serves MCP at POST /mcp using the 2026-07-28 stateless protocol. Each request gets a fresh MCP server instance, so requests can land on any replica without session affinity or shared protocol state. The same endpoint also accepts 2025-era Streamable HTTP clients in stateless compatibility mode.
MCP_HTTP_HOST=127.0.0.1 \
PORT=3000 \
MCP_AUTH_TOKEN=your-secret \
npx -y -p @notharshhaa/devops-mcp@latest devops-mcp-httpConnect clients to http://127.0.0.1:3000/mcp. For a container or remote service, set MCP_HTTP_HOST=0.0.0.0 and configure MCP_ALLOWED_HOSTS with the public/proxy hostnames. Put the service behind TLS for team use.
The deprecated devops-mcp-sse binary remains as a temporary alias for the HTTP entry, but /sse, /message, and /ws now return HTTP 410. Legacy HTTP+SSE and non-standard WebSocket clients must migrate to Streamable HTTP.
No initialize requirement or Mcp-Session-Id on modern requests.
server/discover, per-request client metadata, and MCP-Protocol-Version are handled by the official SDK.
Mcp-Method and Mcp-Name headers are validated against the JSON-RPC body for gateway routing and authorization.
server/discover and tools/list advertise deterministic, public cache hints using MCP_CACHE_TTL_MS (default 60 seconds).
Destructive tools accept confirm: true; modern clients may instead complete an MRTR interactive confirmation. Confirmation state is HMAC-signed, expires after five minutes, and is bound to the exact tool arguments. Global dry-run blocks before prompting.
MCP_REQUEST_STATE_SECRET must be the same on every replica for MRTR retries to land anywhere. When omitted, the server derives the key from MCP_AUTH_TOKEN, or uses a process-local random key when no token is configured.
2025-era Streamable HTTP and stdio clients remain supported. Sessionful HTTP and legacy HTTP+SSE are not.
The built-in MCP_AUTH_TOKEN is a static bearer-token gate, not an OAuth authorization server. For Internet-facing deployments, terminate TLS and enforce your organization’s OAuth/OIDC policy at a gateway or integrate a dedicated identity provider; do not use deprecated Dynamic Client Registration for new deployments.
A minimal docker-compose.yml is available in examples/.
devops-mcp is designed for internal use inside a trusted network. That said:
Kubernetes: Uses standard kubeconfig via @kubernetes/client-node. Supports exec plugins (AWS EKS, GKE). In-cluster: auto-mounts SA token. Add RBAC rules scoped to your desired permissions — run devops-mcp under a dedicated ServiceAccount with minimal verbs. Context selection is fixed by K8S_CONTEXT at startup; the tool only previews changes because runtime switching would affect other callers.
ArgoCD: Generate a long-lived token: argocd account generate-token --account devops-mcp. Create a dedicated account in argocd-cm with apiKey capability and a role limited to read + sync.
Prometheus: Usually unauthenticated inside a cluster. If using Grafana Mimir or Thanos with auth, pass a Bearer token. All tools are read-only so minimal permissions are needed.
PagerDuty: Create a dedicated API key in PagerDuty → API Access → Create New API Key. Use Full Access if you want acknowledge/escalate tools; Read-only if you want a safe-only mode.
Mutations are dry-run by default. Every mutating tool defaults dry_run: true. The AI must explicitly pass dry_run: false — it won't do this unless the user clearly requests an action.
Destructive tools require confirmation. Pass confirm: true directly, or use a 2026-07-28 client that supports the server's MRTR confirmation request. DEVOPS_MCP_DRY_RUN=true blocks execution even after confirmation.
Audit log. Set DEVOPS_MCP_AUDIT_LOG to a file path. Every tool call is written as a JSONL line with timestamp, tool name, parameters, and outcome. Mutations and destructive calls are flagged.
Global dry-run mode. Set DEVOPS_MCP_DRY_RUN=true to block every executing mutation, even when a caller passes dry_run: false. Safe previews remain available — useful for read-only team deployments.
Client / UI agents (Claude Desktop, Claude Code, gateways)
│
▼
MCP v2 Serving Layer
┌──────────────────────────────────────────┐
│ serveStdio │ POST /mcp │
│ 2025 + 2026 eras │ stateless per request │
│ │ routing/header checks │
└──────────────────────────────────────────┘
│
▼
Server Factory & Tool Registry
┌──────────────────────────────────────────┐
│ Fresh protocol instance per HTTP request │
│ Deterministic tool catalog + cache hints │
│ MRTR confirmation for destructive tools │
│ Audit logging and error normalization │
└──────────────────────────────────────────┘
│
▼
┌─────┬──────┬──────┬──────┬──────┬──────┐
k8s argo prom pd logs helm
│
▼
Dry-run guard │ Namespace policy │ Provider credentialsKey architectural features:
Stateless remote protocol: each /mcp request creates a fresh server instance; no protocol session ID or sticky load balancing.
Dual-era compatibility: official SDK entries serve 2026-07-28 and compatible 2025-era stdio/Streamable HTTP clients.
Gateway-friendly routing: modern method and tool headers are validated before dispatch.
Safe caching: deterministic tools/list ordering and configurable public cache hints.
Provider isolation: each provider remains independently configured and safely skipped when unavailable.
Contributions are welcome. The most useful areas:
New providers — Grafana, Datadog, Vault, Terraform Cloud, Flux CD
New tools — within existing providers (e.g. k8s__get_node_pressure, argo__get_app_logs)
Better output formatting — richer structured responses for specific resource types
Tests — unit tests for provider logic using mocked clients
Create src/providers/yourprovider/ with index.ts, client.ts, and one file per resource group.
Register it in src/server.ts.
Add config keys to .env.example and src/config.ts.
Document tools in this README following the existing table format.
Open a PR.
git clone https://github.com/NotHarshhaa/devops-mcp
cd devops-mcp
npm install
cp .env.example .env
npm run dev # tsx watch — restarts on file changeRun against a local kind/minikube cluster for Kubernetes testing. Use DEVOPS_MCP_DRY_RUN=true to prevent accidental mutations during development.
Grafana provider (grafana__*) — dashboards, annotations, datasources
Flux CD provider (flux__*) — kustomizations, helm releases, image automation
Terraform Cloud provider (tfc__*) — workspace runs, state, variables
HashiCorp Vault provider (vault__*) — secret read (never write), lease status
Datadog provider (dd__*) — metrics, monitors, events
Web UI for provider health, task progress, and audit events
MIT — see LICENSE.
Built for DevOps and platform engineers who want AI that actually knows what's happening in their cluster.
Apply a manifest string with server-side dry-run
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | Server-side dry-run (default: true) | |
| manifest | Yes | YAML or JSON manifest string | |
| namespace | No | Namespace to apply in (default: from manifest or "default") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavior. It mentions 'server-side dry-run' but does not disclose that setting dry_run to false results in actual cluster mutation, nor does it address permissions, idempotency, or side effects.
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 sentence, efficient but lacking details. It is front-loaded but too terse to convey essential information.
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 complexity (3 parameters, no output schema, no annotations), the description is insufficient. It omits return values, error cases, and comparison with sibling tools.
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%, so the schema already documents all parameters. The description adds no new parameter-level information 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 specifies 'Apply a manifest string with server-side dry-run', clearly indicating the verb 'apply' and resource 'manifest'. It distinguishes from read-only tools but does not differentiate from similar mutating tools like 'delete_resource' or 'diff_resource'.
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 such as 'k8s__diff_resource' for previewing changes or 'k8s__delete_resource' for removals. The agent has no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a named resource — requires confirm: true
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| confirm | Yes | ||
| namespace | No | ||
| resourceType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that confirm must be true, which is a key behavioral trait. However, it omits other important traits like whether deletion is cascading, permissions needed, or if it's irreversible.
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 and front-loaded, but the brevity sacrifices essential information. It is concise but not optimally structured for completeness.
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 delete operation, 4 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain what resources can be deleted, how to specify them, or the outcome.
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%, so description should add meaning. It only hints at confirm parameter behavior, ignoring resourceType, name, and namespace entirely. This is insufficient.
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 states it deletes a named resource, which is clear. However, it does not specify which resource types are supported, leaving ambiguity. It distinguishes from siblings by being a delete action, but lacks resource type specificity.
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 describe_resource or list resources. The mention of 'requires confirm: true' is a requirement, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full describe for any resource type
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| namespace | No | ||
| resourceType | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Full describe for any resource type' but does not disclose output format, verbosity, potential errors, or required permissions. The agent lacks behavioral context beyond the basic operation.
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 under-specified; it is too short and lacks necessary details. While it is front-loaded, it is not concise enough to be useful—missing critical information makes it insufficient.
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 complexity of Kubernetes describe operations and the existence of many sibling tools, the description does not sufficiently differentiate this tool. No output schema exists, and the description fails to convey what information is returned or how it compares to tools like k8s__get_resource_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 description coverage is 0%, and the description adds no parameter-level information. The three parameters (name, namespace, resourceType) are not explained, e.g., valid resource types or namespace defaults.
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 'Full describe for any resource type' clearly indicates the tool performs a describe operation on any Kubernetes resource. It uses a specific verb (describe) and resource (any resource type), and it distinguishes from sibling list tools like k8s__list_pods which only list resources.
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 like k8s__get_resource_usage or k8s__diff_resource. It does not mention prerequisites, when not to use it, or how it differs from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare current resource state against last-applied-configuration annotation to show drift
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Resource name | |
| namespace | No | Namespace (default: default) | |
| resourceType | Yes | Resource type: deployment, service, configmap, statefulset, daemonset |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the tool compares to show drift but does not disclose whether it is read-only, what happens if annotation is missing, or other behavioral traits like return format or authentication requirements.
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 sentence, concise and to the point. However, it could be slightly improved by front-loading the core action.
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?
The description lacks details on output format, expected drift representation, prerequisites, and error cases. Given no output schema and a diff operation, this is insufficient for an agent to fully understand the tool's 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 100%, so baseline is 3. The description adds context about the comparison target (last-applied-configuration) but does not enhance parameter-specific meaning beyond the schema's simple descriptions.
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 compares current resource state against last-applied-configuration to show drift, which is specific and distinguishes from sibling tools like k8s__describe_resource.
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 drift detection but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or prerequisites like the resource having the last-applied annotation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detailed status of a specific cronjob including recent job history
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | CronJob name | |
| namespace | No | Namespace (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits, but it only states what is returned, not side effects, errors, or permissions.
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, front-loaded sentence with 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?
The description hints at output contents but lacks detail; given no output schema, more clarity on response structure would be helpful.
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 parameter descriptions, so baseline is 3; the description adds no extra semantic value 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 detailed status of a specific cronjob including recent job history, distinguishing it from list tools like k8s__list_cronjobs.
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 k8s__describe_resource or k8s__list_cronjobs is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cluster or namespace events, filterable by reason
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | ||
| reasonFilter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose behavioral traits such as whether it is read-only, pagination behavior, or how filtering works. Minimal transparency.
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 and front-loaded, but it sacrifices clarity for brevity. It could include more useful information without being 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 lack of annotations, output schema, and low schema coverage, the description is incomplete. It fails to mention output format, default behavior, or filter semantics.
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 only hints at 'reasonFilter' but does not clarify 'namespace' or provide format details. Parameters are under-explained.
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 identifies the resource ('events') and scope ('cluster or namespace') and mentions filtering by reason. It distinguishes from sibling tools, but lacks an explicit verb like 'get' or 'list', making it slightly 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. The description does not provide context for appropriate usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get HorizontalPodAutoscaler details with metrics, replicas, and conditions
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | HPA name (omit to list all) | |
| namespace | No | Namespace (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as read-only safety, required permissions, or side effects. For a tool named 'get', it is likely safe, but the description should explicitly state this.
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, terse sentence that conveys the core purpose efficiently with no extraneous words. Front-loads the action 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?
For a simple read operation with no output schema, the description mentions key return fields, which is helpful. It is adequate for an agent to understand what the tool does, though it could explicitly state it is read-only.
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 covers both parameters with clear descriptions (name and namespace). The description adds context about returned fields (metrics, replicas, conditions) but does not enhance parameter meaning 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?
Clearly states the action 'Get', resource 'HorizontalPodAutoscaler', and includes relevant details 'metrics, replicas, and conditions'. Distinct from sibling tools which target different Kubernetes resources.
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 is self-explanatory for basic usage, but provides no explicit guidance on when to use this tool versus alternatives like k8s__describe_resource or k8s__get_resource_usage, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List ingresses with hosts, paths, backends, and TLS config
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Namespace (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states 'list ingresses', which implies a read operation, but does not disclose any behavioral traits such as pagination, permission requirements, or side effects.
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, front-loaded with verb and resource, no 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description covers the returned fields adequately. Could mention that it uses the current context or namespace from input, but still is complete for a simple list tool.
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 the parameter description already defining 'namespace' and its default. The description does not add additional semantic meaning beyond that.
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 uses specific verb 'List' and resource 'ingresses', and details the fields returned (hosts, paths, backends, TLS config). This clearly distinguishes from sibling tools like k8s__list_pods or k8s__list_services.
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 when-to-use or when-not-to-use guidance. The description implies it is for retrieving ingress details but does not mention alternatives or exclusions. Usage is implied from the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List network policies with podSelector, ingress/egress rules
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Namespace (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, description only states it lists policies with certain fields. Does not disclose read-only nature, authorization needs, or whether it returns all policies or filtered by namespace. Lacks important behavioral context for a mutation-ambiguous 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?
Single sentence, no fluff. Front-loaded with action 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?
No output schema, but description provides some info on returned content. For a simple tool with one optional parameter, this is mostly adequate, though could explicitly state it returns a list of policy objects.
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 covers 100% of parameter meaning (namespace with default). Description adds value by indicating the output includes podSelector, ingress/egress rules, which is not in 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?
Description uses specific verb 'List' and resource 'network policies', and mentions included items (podSelector, ingress/egress rules). Clearly distinguishes from sibling tools focused on pods, logs, deployments, etc.
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 like k8s__describe_resource. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get node status with conditions, capacity, allocatable, labels, and taints
| Name | Required | Description | Default |
|---|---|---|---|
| nodeName | No | Node name (omit to list all nodes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It does not disclose any behavioral traits such as read-only nature, required permissions, error handling, or whether it can return all nodes if name is omitted (though schema implies this).
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 concise sentence with no wasted words. It is front-loaded with the main action. However, it could include a bit more detail 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?
The tool is simple with one optional parameter and no output schema. The description lists the returned attributes, which is helpful. However, it omits that omitting nodeName lists all nodes (only in schema), and does not clarify the output structure or potential errors.
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 baseline is 3. The description adds no parameter-specific meaning beyond the schema, but does not repeat or contradict it.
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 'node status' and lists specific attributes (conditions, capacity, allocatable, labels, taints), distinguishing it from sibling tools that operate on pods, deployments, etc.
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 does not provide any guidance on when to use this tool versus alternatives. It neither mentions prerequisites, nor when not to use it, nor suggests alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get logs from a pod container
| Name | Required | Description | Default |
|---|---|---|---|
| pod | Yes | ||
| follow | No | ||
| container | No | ||
| namespace | Yes | ||
| tailLines | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description is the sole source of behavioral information. It only implies a read operation but does not disclose traits like whether following logs is supported, any rate limits, or required permissions. The description is insufficient for an agent to understand side effects or constraints.
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 sentence, which is concise but severely under-specified. It lacks critical details that would make it useful, so it is not effectively concise—it sacrifices completeness for brevity.
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 5 parameters, no schema descriptions, no annotations, and no output schema, the description is grossly incomplete. It does not explain what the return value looks like, how to handle streaming logs, or any constraints, making it inadequate for an agent to use the tool correctly.
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% for 5 parameters, and the description adds no meaning beyond the tool's name. It fails to explain what 'pod', 'namespace', 'container', 'follow', or 'tailLines' do, leaving the agent to guess or rely on schema structure alone.
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 'Get logs from a pod container', identifying the verb and resource. It distinguishes from sibling tools like k8s__list_pods and k8s__describe_resource, but could be more precise by noting that logs can be from a specific container within a pod.
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. It does not mention prerequisites (e.g., pod must exist) or exclusions (e.g., when not to use). Siblings like k8s__describe_resource might also provide log-related info, but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CPU/mem usage per pod via metrics-server
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions dependency on metrics-server but fails to disclose behavior if unavailable, response format, or permissions needed.
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?
Extremely short, one clause. Not verbose, but lacks detailed structure. Could benefit from separating purpose from parameter usage.
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?
Tool returns resource usage but no output schema or behavioral details. With no annotations and sparse description, agents lack context for correct usage and interpretation of results.
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%. Description does not explain the 'namespace' parameter beyond its presence, leaving agents without clarity on its effect (e.g., scoping to specific namespace).
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?
States it gets CPU/mem usage per pod via metrics-server. Verb and resource are clear, but could be more specific about what 'usage' entails (e.g., current vs historical).
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 siblings like k8s__list_pods or k8s__describe_resource. Implies use for metrics, but no when-not or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All kubeconfig contexts and the active one
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not state that the tool is read-only or non-destructive. Although listing operations are typically safe, the description should explicitly clarify behavioral traits.
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 one sentence, front-loading the key information. It is not verbose, but could be slightly more structured to improve readability.
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 parameterless tool, the description is minimally complete. It states what is listed but omits details like output format or additional context cues that could aid 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?
There are no parameters, so the schema covers everything. The description adds value by specifying that the output will indicate which context is active, which is not inferable from the schema alone.
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 indicates the tool returns all kubeconfig contexts and highlights the active one. The verb 'list' is implied by the tool name and reinforced by the description, though not explicitly stated.
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 k8s__switch_context or k8s__describe_resource. The context is missing, making it difficult for the agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List cronjobs with schedule, suspend status, active jobs, and last run times
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Namespace (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses what fields are returned but lacks details on pagination, filtering, or error behavior. Adequate but not thorough.
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, no fluff, directly states purpose and key details. Efficient and front-loaded.
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 listing tool with one optional parameter, the description adequately covers the output fields. No output schema is present, but the description compensates by naming the returned fields.
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%, so the description adds no additional meaning beyond the schema's parameter description. The schema already explains 'namespace' and its default. 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 the action ('List') and resource ('cronjobs'), and specifies the fields returned (schedule, suspend status, etc.), distinguishing it from sibling tools like k8s__list_pods or k8s__list_deployments.
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 (e.g., k8s__get_cronjob_status for a single cronjob). The agent must infer from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deployments with replica counts and rollout health
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. While 'list' implies a read-only operation, there is no explicit statement about safety, side effects, or permissions. The description only hints at the return content, not behavior.
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 and front-loaded but is a noun phrase rather than a complete sentence. While concise, it omits important details, making it under-specified rather than efficiently informative.
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 or annotations, the description should fully explain the tool's scope. It mentions return data but does not address namespace optionality, default behavior (e.g., all namespaces), pagination, or ordering, leaving gaps for agent decision-making.
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 single parameter 'namespace' is not mentioned in the description. With 0% schema description coverage, the description must compensate but fails to explain the parameter's role or filtering behavior.
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 indicates the tool lists deployments and specifies included information (replica counts, rollout health), distinguishing it from other list tools like list_pods or list_services. However, it lacks an explicit verb and could be slightly more precise.
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 (e.g., list_pods for pods, describe_resource for details). Does not clarify namespace filtering or default behavior, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pods with status, restarts, node, and age
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Namespace (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action and columns. Does not disclose read-only nature, permission requirements, pagination, or limits.
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, no fluff. Efficiently conveys the core purpose.
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?
Minimally adequate for a simple list tool with one optional param. Lacks details on return format or behavior (e.g., all pods, pagination). No output schema.
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% and the namespace parameter already has a description. The tool description adds no extra meaning beyond the schema, so baseline 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?
Description clearly states the verb 'List' and resource 'pods', and specifies the columns (status, restarts, node, age). It distinguishes from sibling tools like describe_resource, get_pod_logs, etc.
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. No description of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List PersistentVolumeClaims with status, capacity, accessModes, and storageClass
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Namespace (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure responsibility. It correctly implies a read-only listing operation but does not elaborate on aspects like scope (e.g., all namespaces if none specified) or pagination. The behavior is minimally transparent.
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, well-structured sentence that conveys the core function without redundant information. It is front-loaded and efficient.
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 simplicity of the tool (one optional parameter, no output schema), the description is fairly complete. It names the resource and key fields, though it could optionally mention that omitting the namespace defaults to 'default' for 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?
The input schema has 100% coverage for its single 'namespace' parameter, so the description does not need to add additional parameter details. It does not enhance the schema's explanation, meeting the baseline expectation.
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 lists PersistentVolumeClaims and specifies the fields returned (status, capacity, accessModes, storageClass). It effectively distinguishes itself from sibling tools like k8s__list_pods or k8s__list_deployments by targeting a specific Kubernetes resource.
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 when you need to list PVCs but offers no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Usage is inferred rather than explicitly directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List services with type, clusterIP, ports, selector, and externalIPs
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | Namespace (default: default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that services are listed with specific fields but omits details like listing across all namespaces (default behavior), pagination, or error handling. Adequate but not thorough.
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 clear, front-loaded verb ('List services') and no extraneous words. All information is necessary and well-structured.
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 one optional parameter and no output schema, the description sufficiently conveys what the tool returns. Minor omission of when to use vs siblings, but overall 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?
Schema coverage is 100% (parameter described). The description adds no additional parameter semantics beyond what the schema already provides. Baseline score 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 the tool lists services and enumerates key fields returned (type, clusterIP, ports, selector, externalIPs), distinguishing it from sibling tools like list_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?
No guidance on when to use this tool vs alternatives (e.g., list_pods, list_deployments). With 20 sibling tools, explicit usage context would significantly improve selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger rolling restart of a deployment
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| dry_run | No | ||
| namespace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'restart' without detailing side effects, permissions needed, rate limits, or what happens to the deployment during the restart.
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 sentence, which is concise, but it sacrifices valuable information. It could be expanded slightly to include parameter 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 lack of an output schema and minimal input schema descriptions, the description provides insufficient context. It does not explain required inputs, the effect of dry_run, or the deployment identification, making it incomplete for effective tool 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 description coverage is 0%, and the description does not explain any of the three parameters (name, namespace, dry_run). It offers no meaning beyond the schema's raw definition.
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 'trigger' and the resource 'rolling restart of a deployment', making the tool's purpose immediately understandable. It distinguishes from siblings like 'scale_deployment' as a distinct action.
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, such as prerequisites or conditions. The description does not mention when not to use it or related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scale replicas with dry-run diff preview
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| dry_run | No | ||
| replicas | Yes | ||
| namespace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, placing full burden on description. Only mentions dry-run diff preview, but does not disclose that scaling modifies the deployment spec, may cause pod restarts, or requires certain permissions. The behavioral traits of this mutation tool are insufficiently described.
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 (5 words) and front-loaded with action and feature. No wasted words. However, it could be slightly expanded to improve completeness without sacrificing 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 4 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the dry-run diff preview output, the effect of scaling on the deployment, or prerequisites. Incomplete for a mutation tool that modifies cluster state.
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 0%; description adds minimal context for dry_run parameter ('dry-run diff preview') but nothing for name, namespace, or replicas. No details on format or meaning beyond what schema types imply. Fails to compensate for missing schema descriptions.
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 'Scale replicas with dry-run diff preview' clearly states the action (scale) and resource (replicas). The tool name includes 'deployment', so the resource type is implied. It distinguishes from siblings like k8s__rollout_restart or k8s__apply_manifest by specifying scaling with a dry-run preview feature.
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 like k8s__rollout_restart or k8s__apply_manifest. No prerequisites (e.g., deployment must exist) or context for when the dry-run feature is beneficial. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch active context (session-scoped)
| Name | Required | Description | Default |
|---|---|---|---|
| contextName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. The phrase 'session-scoped' discloses that the change is temporary, but other behavioral traits (e.g., error handling, authorization needs) are absent.
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, which is acceptable for a simple tool, but it sacrifices necessary detail. It is front-loaded but lacks completeness.
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 absence of annotations and output schema, the description should compensate. It only provides scope information but omits key details like contextName existence validation, making it insufficient for reliable agent use.
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 adds no meaning to 'contextName' beyond its name. The agent must infer the parameter's role from the tool name alone.
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 action ('Switch active context') and scope ('session-scoped'). The verb-resource pair is specific and distinguishes from siblings like 'list_contexts'. However, it could be more explicit about Kubernetes context.
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. The description does not mention that the context must exist, nor does it provide any prerequisites or post-conditions.
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.
v2.1.0k8s__apply_manifestk8s__delete_resourcek8s__describe_resourcek8s__diff_resourcek8s__get_cronjob_statusk8s__get_eventsk8s__get_hpak8s__get_ingressesk8s__get_network_policiesk8s__get_node_statusk8s__get_pod_logsk8s__get_resource_usagek8s__list_contextsk8s__list_cronjobsk8s__list_deploymentsk8s__list_podsk8s__list_pvcsk8s__list_servicesk8s__rollout_restartk8s__scale_deploymentk8s__switch_contextEach tool targets a distinct resource-action pair with clear descriptions. For example, list_pods, get_pod_logs, and describe_resource are all distinct. No overlapping functionality.
All tools follow the pattern `k8s__verb_noun`. Verbs are consistent (list, get, describe, etc.), but there is minor inconsistency in singular vs plural nouns (e.g., get_pod_logs vs list_pods). Overall pattern is strong.
21 tools cover a wide range of Kubernetes operations from monitoring to management. The count is slightly on the high side but well-scoped for a comprehensive DevOps tool.
Covers many common tasks (viewing, scaling, applying manifests) but lacks explicit create/update operations for many resource types (beyond apply). Missing rollback, secrets/configmaps, and other lifecycle operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Devopness MCP server for DevOps happiness! Empower AI Agents to deploy apps and infra, to any cloud.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Unified MCP Server is a remote MCP connector for AI agents and vertical AI products that provides access to 22,000+ authorized SaaS tools across 400+ integrations and 24 categories directly inside LLMs (Claude, GPT, Gemini, Cohere). Tools operate only on explicitly authorized customer connections, enabling agents to safely read and write against live third-party systems.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/NotHarshhaa/devops-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
