Kubernetes Manifest Audit MCP Server

kube-linter audit for Kubernetes manifests — 63 checks: security, availability, RBAC, network. That is what the kubernetes manifest audit mcp server brings to an AI assistant: the same capability, reachable through the Model Context Protocol rather than a separate app or dashboard.

The short version

Point any MCP-capable client (Claude Desktop, Cursor, n8n, Make, Zapier, custom agents) at this server, hand it a Kubernetes manifest or directory of manifests, get back a structured report:

• Severity — — high / medium / low / info
• Check ID — — kube-linter check name (e.g. privileged-container, unset-cpu-requirements)
• Category — — security / resources / availability / network / rbac / images / config
• Message — — what kube-linter found and where
• Remediation hint — — what to do about it
• Object location — — kind, name, namespace of the offending resource

Getting it running

Setup follows the usual MCP pattern — install or clone the server, register it in your client's configuration file, restart the client. The configuration blocks on this page cover the common clients.

What it needs from you

Configuration is passed through the environment: YOUR_APIFY_TOKEN. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.

Things to watch

• It runs with your machine's permissions. That is convenient and also the reason to think about what you point it at before you approve a tool call.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• Keep per-call confirmation enabled while you learn its behaviour; it is the cheapest safeguard you have.

How it compares

This sits in the cloud and infrastructure group, where several servers overlap in what they claim to do but differ sharply once you actually set them up. It is maintained by UnbearableDev; worth a glance at recent repository activity before you build anything load-bearing on it.

We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.