Dockerfile Check
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | The port for the hosted Streamable HTTP server (default 3000). | 3000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_dockerfileA | Checks Dockerfiles: syntax, what breaks the build (apt-get install without -y, copies outside the context, unknown stages), root users, secrets in ENV/ARG, cache order, and each base image against its registry (tag exists, digest to pin, platforms, last rebuild) and end-of-life dates. Findings have line and fix. |
| image_infoA | For container image references (node:20-alpine, ghcr.io/org/app:1.2): whether the tag exists (nearest real tags if not), its digest and a pinned reference, platforms, last rebuild (Docker Hub), and end-of-life status of its runtime and OS with an upgrade tag. Docker Hub, GHCR, Quay, GCR, MCR, ECR Public, registry.k8s.io. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
check_dockerfile is clearly the Dockerfile linter while image_info is the image-reference inspector, so the core purposes are distinct. However, check_dockerfile also validates each base image against its registry (tag existence, digests, platforms, EOL), which overlaps with what image_info does, creating some potential for misselection on image-related queries.
Both names use snake_case consistently, which is readable and predictable. The pattern is slightly uneven (verb_noun 'check_dockerfile' vs noun_noun 'image_info'), a minor deviation rather than a real inconsistency.
Two tools is defensible for this narrow, focused domain (linting Dockerfiles plus inspecting image references). Still, it sits at the thin end and leaves little redundancy or granularity for users who only want one aspect checked.
The pair covers the stated purpose well: Dockerfile lint findings with lines and fixes, plus image tag/digest/platform/EOL data across major registries. Minor gaps remain, such as no autofix output or broader compose-file/context checks, but core workflows are covered.