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: Dockerfile Check
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.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | A local file to lint instead of `content`. | |
| type | No | auto detects Dockerfile vs Kubernetes YAML/JSON. | auto |
| ignore | No | Rule ids to skip, e.g. ["DF-017"]. | |
| content | No | The Dockerfile or manifest, as text (up to 512 KiB). | |
| fail_on | No | `passed` is false at this severity or worse. | high |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds genuinely new behavior: the exact shape of the result (grade, score, `passed`, findings with line, fix and reference), which an agent cannot get from the annotations and which tells it what it will have to parse. It does not state what happens when both or neither input is supplied.
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?
Three short sentences, zero filler. The action and target come first, the return payload second, and the input constraint last, so the reader gets the essentials in reading order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fills that void by enumerating the return fields, and the schema covers the rest of the parameters. The only missing piece is the edge case of conflicting or absent `content`/`path`, which is minor but leaves an agent guessing on an unconstrained parameter set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains `type`, `ignore`, `fail_on` and the size cap. The description still adds meaning beyond it by declaring `content` and `path` mutually exclusive, a constraint the schema does not express (both simply default to null with no oneOf). That is real value on top of an already documented 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?
States a specific verb and two concrete resources ("Lint a Dockerfile or Kubernetes manifest") and immediately scopes the return payload to grade, score, passed and findings. There are no sibling tools to disambiguate from, so the definition is fully self-sufficient for selection.
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 only usage instruction is "Give either `content` or `path`," which is input-shape guidance rather than when-to-use guidance. There are no alternatives to route between, so the gap is small, but no context is given for choosing inline content versus a file path.
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.
v0.2.2lintScored 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.
