MyMCPTools
Guides9 min read

Best MCP Servers for Platform Engineers in 2026

Platform engineers build and maintain internal developer platforms — the infrastructure, tooling, and self-service systems that keep engineering teams moving. These MCP servers give your AI access to cluster state, infrastructure as code, secret management, CI/CD pipelines, and observability data.

By MyMCPTools Team·

Platform engineering is infrastructure work at the speed of product development. Your job is to abstract the complexity of distributed systems into reliable, self-service primitives that product engineers can consume without needing a PhD in Kubernetes. The challenge: the state of those systems is always changing, and understanding it requires pulling context from a dozen different tools.

MCP servers collapse that context into a single conversation. Instead of switching between kubectl, Terraform, Vault, Grafana, and GitHub Actions to diagnose a problem or plan a change, your AI can query all of them at once. Here are the best MCP servers for platform engineers in 2026.

1. Kubernetes MCP Server — Live Cluster State as Context

The cluster is the platform. The Kubernetes MCP server gives your AI direct access to cluster state — pods, deployments, services, namespaces, config maps, events, and resource quotas — making it possible to reason about operational issues and configuration changes with real data rather than stale documentation.

Key capabilities:

  • Query pod status, logs, and events across namespaces
  • Inspect deployment rollout history and current replica counts
  • Check resource quota consumption by namespace or team
  • Read config maps and secrets metadata for configuration auditing

Best for: Diagnosing why a team's deployment is failing without opening a terminal. Ask "what's happening in the payments namespace right now?" and get pod status, recent events, and resource pressure in one response. Excellent for capacity planning discussions where current utilization needs to be grounded in real numbers.

2. Terraform MCP Server — Infrastructure as Code at Scale

Platform infrastructure is code. The Terraform MCP server gives your AI access to your infrastructure declarations — module trees, resource dependencies, state, and planned changes — so infrastructure design conversations can reference the actual configuration rather than diagrams that drift from reality.

Key capabilities:

  • Read module structures and resource dependency graphs
  • Query Terraform state for current infrastructure inventory
  • Review planned changes before apply to catch unintended side effects
  • Search for resource patterns or anti-patterns across environments

Best for: Architecture reviews where you need to understand what's actually deployed. Ask "what AWS resources does the data platform module create?" and get a precise answer from the actual Terraform configuration — not from someone's memory of what they think they shipped six months ago.

3. Vault MCP Server — Secret Management and Access Auditing

Secret sprawl is the silent killer of platform security. The Vault MCP server gives your AI visibility into your secret management posture — engines, policies, lease TTLs, and access patterns — making it easier to audit access, enforce rotation policies, and diagnose authentication issues without manually navigating the Vault UI.

Key capabilities:

  • Audit secret engine configurations and mount paths
  • Review policy definitions for over-permissioned access
  • Check token lease TTLs and renewal patterns
  • Diagnose authentication failures by reviewing auth method configurations

Best for: Quarterly security reviews where you need to audit who has access to what, and whether rotation policies are being enforced. Ask "which services have leases expiring this week?" before a high-traffic event to avoid authentication failures from stale credentials.

4. GitHub Actions MCP Server — CI/CD Pipeline Intelligence

The CI/CD pipeline is your platform's delivery nervous system. The GitHub Actions MCP server gives your AI access to workflow runs, job logs, failure patterns, and pipeline configuration — so you can diagnose build failures, identify flaky tests, and optimize pipeline performance without manually trawling through run logs.

Key capabilities:

  • Read recent workflow run results across repositories
  • Access job logs to diagnose build failures
  • Identify recurring failure patterns across runs
  • Review workflow configuration for optimization opportunities

Best for: Platform teams responsible for build reliability who want AI to identify why a specific workflow has been failing intermittently, or to audit whether teams are following established pipeline patterns before approving new workflow additions.

5. Prometheus MCP Server — Metrics as Operational Context

Platform health is measured in metrics. The Prometheus MCP server gives your AI access to your metrics data — cluster resource utilization, service SLIs, custom business metrics, and alerting rules — so reliability discussions can be grounded in real performance data rather than intuition.

Key capabilities:

  • Query time-series metrics for infrastructure resources
  • Read alerting rules to understand current monitoring coverage
  • Check metric cardinality for scalability assessment
  • Evaluate recording rule efficiency for high-cardinality queries

Best for: Capacity planning conversations where you need to project resource growth from current utilization trends. Ask "based on current memory growth, when do we need to add nodes to the production cluster?" and get an answer grounded in actual metric data rather than guesswork.

6. Helm MCP Server — Release Management and Chart Intelligence

Helm charts are how platform teams package and distribute standardized workloads. The Helm MCP server gives your AI access to chart definitions, release histories, and value configurations — so you can audit what's deployed, diagnose release failures, and maintain chart hygiene across environments.

Key capabilities:

  • Inspect chart templates and default value schemas
  • Read release histories and rollback availability
  • Compare values between environments to identify configuration drift
  • Review chart dependencies for version compatibility

Best for: Diagnosing environment-specific issues caused by value overrides. Ask "how do the production values for the API gateway chart differ from staging?" to quickly identify why a service behaves differently across environments without manually diffing YAML files.

7. Grafana MCP Server — Dashboards and Alert Context

Grafana is the observation layer of most platform stacks. The Grafana MCP server gives your AI access to dashboard definitions, panel queries, and alert configurations — making it possible to audit monitoring coverage, update dashboards, and understand what's being measured without navigating the Grafana UI manually.

Key capabilities:

  • Read dashboard definitions and panel configurations
  • Audit alert rules for correctness and coverage gaps
  • Search for dashboards related to a specific service or metric
  • Review data source configurations for connection issues

Best for: Onboarding new services onto the platform's observability stack. Ask "do we have dashboards covering the key SLIs for the payment service?" and get an assessment of current monitoring coverage before the service goes to production.

8. Argo CD MCP Server — GitOps Delivery State

GitOps means the cluster state should match the Git state. The Argo CD MCP server gives your AI visibility into your application synchronization status — which apps are out of sync, which are degraded, and what the git diff looks like between desired and actual state — making GitOps drift easy to detect and diagnose.

Key capabilities:

  • List applications and their current sync status
  • Read sync errors and health assessment for degraded apps
  • Review application manifests and target revisions
  • Check sync policy configurations for auto-sync enforcement

Best for: Platform teams operating GitOps workflows who need to quickly assess the delivery state of the entire fleet. Ask "which production applications are out of sync right now and why?" to get a prioritized list of drift incidents before your daily platform review.

Recommended Stacks for Platform Engineers

  • Incident diagnosis: Kubernetes + Prometheus + Grafana (cluster state → metrics → dashboards)
  • Infrastructure review: Terraform + Vault + GitHub Actions (IaC state → secrets posture → CI/CD health)
  • Release management: Argo CD + Helm + GitHub Actions (GitOps state → chart config → pipeline logs)
  • Capacity planning: Kubernetes + Prometheus + Terraform (current utilization → trends → IaC for scaling)
  • Full platform stack: Kubernetes + Terraform + Vault + Prometheus + Grafana + Argo CD — complete coverage across runtime, infrastructure, security, and observability

Browse all DevOps MCP servers on MyMCPTools. For related guides, see Best MCP Servers for DevOps and Best MCP Servers for Site Reliability Engineers.

Recommended Tools

Better Stack

Free Plan

Get alerted when your APIs, browser tests, payment pipelines, or MCP server dependencies go down. Used by 100K+ developers.

Start monitoring free →

1Password

14-day Free Trial

Store and inject API keys, payment credentials, tokens, and file access secrets into your MCP server configs. Trusted by 150K+ developers.

Try 1Password free →

🔧 MCP Servers Mentioned in This Article

🔧

Kubernetes MCP Server

The Kubernetes MCP server (mcp-server-kubernetes, built by Flux159) brings cluster management capabilities into AI assistant workflows, letting developers and platform engineers query and manage Kubernetes resources through natural-language interactions with Claude, Cursor, and other MCP-compatible clients. It loads your existing kubeconfig automatically, so it works with any cluster — local minikube and kind setups, Amazon EKS, Google GKE, Azure AKS, or on-premises deployments — with no separate credential setup required. Core tools exposed by the server include: listing pods, deployments, services, and namespaces; describing individual resources and their status; fetching pod logs for debugging; applying and updating manifests; scaling deployments; checking rollout status and history; and querying resource utilization and cluster events. A built-in non-destructive mode can disable delete/scale-down operations entirely, making it safe to point at production clusters for read-only diagnostics. DevOps engineers use it to debug failing deployments by asking Claude to inspect pod logs and recent events, identify resource constraints causing OOMKilled pods, or summarize the current state of a namespace before a production release. For SREs responding to incidents, it enables rapid triage through conversational commands — no memorizing kubectl flags or switching terminal windows mid-incident — and optional OpenTelemetry integration adds observability into what the AI agent actually did against the cluster. Install with: `npx mcp-server-kubernetes`. Pairs well with the GitHub MCP server for full GitOps review workflows.

Local
🔧

Terraform MCP Server

live Terraform Registry data — provider schemas, module inputs and outputs, policy libraries — plus full HCP Terraform and Terraform Enterprise workspace management, so an AI assistant writes HCL against the real resource arguments instead of inventing attribute names from memory. HashiCorp distributes it as a Go binary and a Docker image, not as an npm package: `@hashicorp/terraform-mcp-server` returns 404 on the npm registry, so npx configurations copied from older write-ups cannot work. The supported install is the hashicorp/terraform-mcp-server image on Docker Hub (v1.1.0, released 2026-07-14), run with `docker run -i --rm hashicorp/terraform-mcp-server:1.1.0`, or the release binary invoked as `terraform-mcp-server stdio`. Both transports are supported: stdio for local clients, and streamable-http via `terraform-mcp-server streamable-http --transport-port 8080 --mcp-endpoint /mcp` for shared deployments. Registry lookups need no credentials at all — only the HCP Terraform and Terraform Enterprise tools do, via TFE_TOKEN plus TFE_ADDRESS (which must include the protocol, e.g. https://app.terraform.io, and in streamable-http mode can only be set as an environment variable, never supplied by a client header). Two flags matter before you expose it to a team: ENABLE_TF_OPERATIONS is false by default and gates the tools that mutate infrastructure, and the HTTP server defaults to strict CORS with 10:20 global and 5:10 per-session rate limits, an MCP_ORGANIZATION_ALLOWLIST for restricting which HCP organisations can connect, and required MCP_TLS_CERT_FILE / MCP_TLS_KEY_FILE for any non-localhost bind. Server instructions live in cmd/terraform-mcp-server/instructions.md and are meant to be replaced with your own conventions if the default answers do not match how your organisation writes Terraform.

Local✓
🔧

HashiCorp Vault

Manage secrets and sensitive data stored in HashiCorp Vault. Read and write secrets, manage dynamic credentials, and handle PKI operations via AI.

Local✓
🔧

GitHub Actions

Manage GitHub Actions workflows, runs, and secrets. Trigger workflows, inspect run logs, manage environment variables, and debug CI failures via AI.

Local✓
🔧

Prometheus MCP Server

The Prometheus MCP Server lets an AI assistant drive a live Prometheus instance through the HTTP API instead of you hand-writing PromQL in the expression browser — ask it why queries got slow, what is currently firing, or which recording rules would make an SLO cheap to evaluate, and it composes and runs the queries itself. One point of provenance worth knowing before you install: this began life as tjhop/prometheus-mcp-server and was adopted into the Prometheus organisation, so that path now 301-redirects to prometheus/prometheus-mcp, while release binaries and container images are still published under the tjhop namespace. The tool surface goes far past a single query endpoint. Instant and range queries (query, range_query, exemplar_query) sit alongside discovery tools — label_names, label_values, metric_metadata, list_targets, alertmanagers — and operational ones: list_alerts, list_rules, config, flags, build_info, healthy, ready, plus TSDB admin endpoints such as clean_tombstones, delete_series, snapshot, reload, wal_replay_status and quit. It also embeds the official prometheus/docs corpus as both tools (docs_list, docs_read, docs_search) and MCP resources under prometheus://docs, so the model can cite metric-naming best practice rather than invent it. Two features exist specifically to keep long investigations inside a context window: optional TOON (Token-Oriented Object Notation) encoding of API responses in place of JSON, and a configurable response-truncation limit that capable models can override per tool call. Prometheus-compatible backends are handled explicitly rather than assumed — a --prometheus.backend flag selects an implementation, and the Thanos profile removes the tools Thanos returns 404 for (config, alertmanagers, quit, reload, the TSDB admin set) while adding list_stores. Install as a Go binary from the releases page, as a Debian/RPM system package with a bundled systemd unit, via the OCI Helm chart at oci://ghcr.io/tjhop/charts/prometheus-mcp-server, or as a container: `docker run --rm -i ghcr.io/tjhop/prometheus-mcp-server:latest --prometheus.url "https://your-prometheus:9090"` for stdio, or add `--mcp.transport http --web.listen-address ":8080"` for streamable HTTP. Every flag has a PROMETHEUS_MCP_SERVER_* environment-variable equivalent. Secured Prometheus instances are reached with a standard Prometheus http_config file via --http.config, and the MCP endpoint itself can be put behind TLS and basic auth with a Prometheus web-configuration file via --web.config.file. Read the credential-forwarding note before exposing it: over HTTP transport the server forwards each request's Authorization header to Prometheus verbatim without validating it, requests without one fall back to the default client's credentials, and basic_auth_users in the web config conflicts with that forwarding — so anyone who can reach the endpoint can query Prometheus as at least the default client.

Local✓
📊

Grafana MCP Server

The official Grafana MCP server connects Claude and other AI assistants directly to your Grafana instance and its surrounding observability ecosystem, turning natural-language questions into dashboard lookups, incident investigations, and datasource queries. Dashboard tools cover search, retrieval, JSONPath-scoped property extraction, patch-based editing, and per-panel query/datasource introspection, with context-window-aware helpers like get_dashboard_summary so an agent never has to pull a full multi-megabyte dashboard JSON just to answer a simple question. Query tools speak PromQL against Prometheus (including histogram-percentile helpers), LogQL against Loki, and native query languages for InfluxDB, ClickHouse, CloudWatch, Graphite, Athena, Snowflake, Elasticsearch/OpenSearch, and Quickwit datasources — most gated behind opt-in --enabled-tools flags to keep the default tool surface lean. It also wraps Grafana Incident for creating and updating incidents, Sift for automated error-pattern and slow-request investigations, full alerting CRUD (rules, contact points, notification policies) across Grafana-managed and external Alertmanager sources, Grafana OnCall schedule/shift/alert-group management, RBAC-gated admin tools for teams/users/roles, deeplink generation so the LLM never has to guess a dashboard URL, annotations, snapshots, PNG rendering via the Grafana Image Renderer, and provisioning-repo validation for git-sync workflows. Authentication is a Grafana service account token (Editor role, or granular RBAC scopes) passed as GRAFANA_SERVICE_ACCOUNT_TOKEN alongside GRAFANA_URL, and every tool category can be individually disabled to control context-window usage. On install, the recommended route is uvx: `uvx mcp-grafana` pulls the PyPI package mcp-grafana, which is published by Grafana Labs from this same repository — so despite the server being written in Go, the copy-paste command most Claude Desktop and Cursor configs use is a Python-tooling one, not a binary download. The alternatives are `go install github.com/grafana/mcp-grafana/cmd/mcp-grafana@latest` for a real binary, or the grafana/mcp-grafana container — `-t stdio` for local clients, or the default HTTP mode on :8000 (add `-t streamable-http`) with MCP_GRAFANA_SERVER_TOKEN set to authenticate callers when you expose it.

Local✓
🔧

Helm

Kubernetes package manager MCP server. Install, upgrade, and roll back Helm charts. Inspect release history, manage repositories, and debug chart templates.

Local✓
🔧

Argo CD MCP Server

the Argo CD MCP server, an Argo Project Labs implementation (argoproj-labs/mcp-for-argocd) that lets an assistant drive a live Argo CD instance in natural language over stdio or HTTP stream transport. Install it with npx argocd-mcp@latest stdio on Node 18+ and give it two things: ARGOCD_BASE_URL and ARGOCD_API_TOKEN. The tool surface is genuinely operational rather than read-only — list_applications, get_application, create_application, update_application, delete_application and sync_application for the application lifecycle; get_application_resource_tree, get_application_managed_resources, get_application_workload_logs, get_resource_events, get_resource_actions and run_resource_action for the Kubernetes objects underneath; plus list_clusters and get_appproject. get_application_workload_logs is the one that changes day-to-day work: it pulls Pod and Deployment logs for a failing app without a kubectl context, so an agent can go from 'this app is degraded' to the actual stack trace in one hop. Two configuration details cause most first-run failures. Self-signed or private-CA certificates on the Argo CD endpoint need NODE_TLS_REJECT_UNAUTHORIZED=0 in the client config, which is a development-only workaround. And the API token is deliberately never accepted as a tool-call argument — it is read only from the x-argocd-api-token header or the ARGOCD_API_TOKEN environment variable, so it never enters a prompt, model context, or tool-call log. For fleets, ARGOCD_TOKEN_REGISTRY_PATH points at a JSON file mapping each base URL to its own token; a call then targets an instance with the non-secret argocdBaseUrl argument and the server pairs it with the registered credential. The default token is bound to the default base URL and is never sent to another host, which is what stops a prompt-injected argocdBaseUrl from exfiltrating it. If the registry file is set but missing or malformed the server fails closed at startup rather than falling back. One more thing worth knowing before you expose it: the http and sse transports open a listener that reaches delete_application and run_resource_action, and ARGOCD_API_TOKEN does not protect it — that token authenticates the server to Argo CD, not the caller to the server. It binds 127.0.0.1 by default; set MCP_AUTH_TOKEN to require Authorization: Bearer on every inbound request before changing MCP_BIND_ADDRESS.

Local📘✓
💻

GitHub MCP Server

authenticated access to the whole GitHub platform — repositories, files, branches, issues, pull requests, Actions runs, security alerts, discussions and notifications — from Claude, Cursor, VS Code, Copilot CLI and any other MCP host. There is no npm package for this server, and that trips up most people who try to install it: `@github/mcp-server` is not published to the npm registry, so any `npx` line you find for it will fail. GitHub ships it three other ways. The easiest is the hosted remote server at https://api.githubcopilot.com/mcp/, which needs no install at all — point an HTTP-transport MCP client at that URL and log in with OAuth (VS Code 1.101+, Claude Desktop, Claude Code, Cursor and Windsurf all support this). The second is the official Docker image ghcr.io/github/github-mcp-server, which is what the copy-paste command on this page runs; on github.com it now performs a browser-based OAuth login on first use and keeps the token in memory only, which is why the published Docker configs map a fixed loopback callback port (-p 127.0.0.1:8085:8085 with GITHUB_OAUTH_CALLBACK_PORT=8085) so the container can receive the callback. Prefer a token? Set GITHUB_PERSONAL_ACCESS_TOKEN instead — it takes precedence over OAuth, and the minimum useful scopes are repo, read:org and read:packages. The third is the native Go binary from the repository's releases, which needs no fixed port for the OAuth flow. GitHub Enterprise Server has no hosted option: use the local server with --gh-host or GITHUB_HOST set to your instance (include the https:// scheme — it defaults to http://, which GHES rejects). Toolsets can be narrowed with GITHUB_TOOLSETS, and an insiders channel is available at /mcp/insiders or via the X-MCP-Insiders header.

Auth required📘✓
📊

Datadog MCP Server

The Datadog MCP Server is Datadog's official, vendor-hosted Model Context Protocol endpoint — not a package. Each Datadog site has its own URL of the form https://mcp.<your-site>/api/unstable/mcp-server/mcp (US1: mcp.datadoghq.com, EU1: mcp.datadoghq.eu), and OAuth 2.0 is the recommended way in; a Personal or Service Access Token as an Authorization bearer header is the documented fallback for CI, with DD_API_KEY plus DD_APPLICATION_KEY headers as a third option. Datadog ships first-party client integrations rather than expecting hand-written config: a Claude Code plugin (/plugin install datadog@claude-plugins-official, then /ddsetup and /ddtoolsets), a Claude connector from the Connectors Directory, plugins for Cursor, VS Code/Copilot, JetBrains and OpenCode, and a ChatGPT app in Preview for US1. Tools are grouped into toolsets selected with a ?toolsets= query parameter, and only `core` — logs, metrics, traces, dashboards, monitors, incidents, hosts, services, events, notebooks — loads by default; two dozen more cover alerting, DBM, DDSQL, RUM, profiling, security, Kubernetes, error tracking, feature flags, cost management and data observability, with apm, cases, code-exec and remote-actions in Preview and excluded from toolsets=all. Access requires the mcp_read or mcp_write role permission in addition to the normal resource permission, which is why a working connection can still return no data. Limits at time of writing are 50 requests per 10 seconds of tool-call burst and 50,000 tool calls per month, and the server is not GovCloud compatible.

Local📘✓

📚 More from the Blog

Guides

Best MCP Servers for Developers in 2026: The Complete Guide

Discover the top MCP servers that every developer should know about. From filesystem access to database queries, these Model Context Protocol servers supercharge your AI coding workflow.

8 min readGuides

Best MCP Servers for Data Engineering: Database, ETL & Analytics

Top MCP servers for data engineers and analysts. Connect your AI to PostgreSQL, BigQuery, Snowflake, and more for AI-powered data workflows.

7 min readTutorials

Getting Started with MCP: A Beginner's Guide to Model Context Protocol

New to MCP? Learn what Model Context Protocol is, how it works, and how to set up your first MCP server in under 5 minutes. Complete beginner's guide.

10 min read