Lints Dockerfiles and Kubernetes manifests to catch security and best-practice issues before deployment.
Lint a Dockerfile or Kubernetes YAML/JSON manifest from inline content or a local file path.
Auto-detect the input type, or force dockerfile or kubernetes.
Check issues such as root in the final stage, unpinned base images, curl | sh, secrets in ENV/ARG, Pod Security Standards, resources, and probes.
Skip specific rule IDs with ignore, e.g. ["DF-017"].
Set fail_on to high, medium, low, info, or never to control whether the result passes.
Return an A–F grade, score, passed status, and every finding with its line, fix, and reference.
Lints Dockerfiles and returns an A–F grade, score, pass/fail status, and findings with line references, fixes, and references. Checks issues such as root in the final stage, unpinned base images, curl | sh usage, and secrets in ENV/ARG.
Lints Kubernetes manifests and returns an A–F grade, score, pass/fail status, and findings with line references, fixes, and references. Checks Pod Security Standards, resource settings, and probes, while noting that NetworkPolicies, PodDisruptionBudgets, and RBAC are not checked.
Click on "Deploy 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., "@Shipshape MCP Server lint ./Dockerfile and tell me what to fix first"
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.
Let your coding agent lint a Dockerfile or Kubernetes manifest before handing it over: root in the final stage, unpinned base images, curl | sh, secrets in ENV/ARG, Pod Security Standards, resources and probes.
The server is open source (MIT). It calls the Shipshape API, which is paid, with a free plan.
You use your own key, from RapidAPI or api.market.
Every tool call is one request on your plan.
The free Basic plan has 15 requests a month, with a hard limit, so it never runs up a bill.
Related MCP server: layerlint-mcp
The server runs locally over stdio with uv. Put your key in its environment.
JSON configuration (Claude Desktop, Cursor, VS Code and most clients):
{
"mcpServers": {
"shipshape": {
"command": "uvx",
"args": ["--from", "bytestay-shipshape-mcp", "shipshape-mcp"],
"env": { "RAPIDAPI_KEY": "your-rapidapi-key" }
}
}
}Claude Code:
claude mcp add shipshape --env RAPIDAPI_KEY=your-rapidapi-key -- uvx --from bytestay-shipshape-mcp shipshape-mcpvariable | meaning |
| your RapidAPI key |
| your api.market key, used when |
|
|
Without a key the server still starts. The first tool call then explains where to get one.
Also listed on Glama:
tool | what it does |
| lints one file and returns the A–F grade, score, |
With path, files named like Dockerfile, *.Dockerfile, Dockerfile.* or Containerfile are linted as Dockerfiles.
passed is false when a finding is at or above fail_on.
Every tool returns the API's JSON response.
When the marketplace reports it, quota_remaining is added: the requests left on your plan this month.
Errors are explained in plain words, with what to do next:
key refused, with the link to subscribe;
quota reached, with the plans;
input the API couldn't process, with the API's reason.
Local files are read only when a tool is given their path. They are sent to the API for that one request.
The API processes inputs in memory and doesn't store them. See the privacy policy.
Your key is only sent to the marketplace you chose.
Files up to 512 KiB.
Helm templates must be rendered first (helm template).
NetworkPolicies, PodDisruptionBudgets and RBAC are not checked.
The server needs Python 3.10+ (uv installs it for you).
uv venv && uv pip install -e ".[dev]"
.venv/bin/pytest # unit tests, no network; 100% coverage required
.venv/bin/ruff check src tests scriptsscripts/e2e_stdio.py shipshape runs the server over stdio, as a client would, and calls its tools against the real API. It needs RAPIDAPI_KEY or API_MARKET_KEY.
MIT. Shipshape itself is a paid API with a free plan, run by ByteStay.
Lint a Dockerfile or Kubernetes manifest. Returns the grade, score, passed and every finding with its
line, fix and reference. Give either content or path.
Inputs: path, type, ignore, content, +1 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 1 tool
There is only one tool, so there is no possibility of misselection between tools. The single tool's purpose (lint a Dockerfile or Kubernetes manifest) is clearly stated, and its two input modes (`content` vs `path`) are handled as parameters rather than as separate overlapping tools.
With a single tool named `lint`, there is no mixed convention to violate; the name is a clear, conventional verb. Consistency is trivially satisfied, though there is no multi-tool pattern to demonstrate predictability.
One tool is on the thin side, but the server's scope is genuinely narrow (static analysis of Dockerfiles and K8s manifests), so a single entry point is defensible. It sits at the borderline of '1-2 tools feels thin' rather than being an extreme mismatch, since the tool itself does substantial work (grade, score, findings, fixes, references).
The core linting lifecycle — submit a manifest and get scored findings with fixes and references — is covered for both Dockerfile and Kubernetes inputs. However, obvious adjacent operations are absent: auto-fix/remediation, batch or directory-level linting, and any rule/config discovery, which leaves agents at a dead end once findings are returned.
Scores your code across 12 areas, with findings, fix prompts, and re-assessment in your AI agent
Free, read-only ship-readiness check for Replit, Lovable and Bolt apps.
Hadolint-grade Dockerfile audit — 19 checks: secrets, privileges, supply chain, hygiene.
Four IaC audits in one call: Compose, Dockerfile, GitHub Actions, Kubernetes. 131 checks.