Skip to main content
Glama

image_import

Imports a root filesystem tarball as a new Docker image without build history.

Instructions

Create an image from a flat root-filesystem tarball, like docker import.

Imports a filesystem archive as a new single-layer image with no build history — not the same thing as image_load, which restores a docker save archive complete with its layers, tags and history, so prefer image_load for anything image_save produced. Use this for a rootfs that came from somewhere else: a container_export archive, a distro base tarball, a VM image dump. The result has an empty config — no CMD/ENTRYPOINT/ENV — unless you supply changes, so an imported image is usually not runnable until you set at least a command. Pass exactly one source (from_file, data, from_url or from_image); ValueError otherwise. from_url and from_image are fetched by the daemon, from_file/data are read here and uploaded; a from_file path that is not a readable file raises rather than being retried as a URL. Unlike the other image-creating tools this stamps no provenance labels: the Engine's import call accepts no labels field, and changes does not cover LABEL.

args: repository - Repository name to give the new image, e.g. "myorg/rootfs"; may include a tag (myorg/rootfs:v1), and defaults to :latest when it does not. Omit to import untagged, addressable only by the id in the returned progress (omit it entirely -- a blank string is a ValueError, not a shorthand for untagged). A digest reference is refused by the daemon. Required if tag is given tag - Tag to apply, e.g. "v1". Overrides a tag already in repository rather than being ignored, so passing repository="myorg/rootfs:v1" with tag="v2" yields :v2. Requires repository (ValueError without it — the daemon would otherwise silently drop the tag and import untagged). Blank is also a ValueError, not a shorthand for the default: the daemon would substitute latest without saying so from_file - Path to a rootfs tarball on the server host (~ expanded), read by the server's user; FileNotFoundError if it is not an existing regular file; exactly one source data - Rootfs tarball contents in band (base64-encoded by MCP, so prefer from_file for anything but small archives); exactly one source from_url - URL the daemon fetches the tarball from; exactly one source from_image - Name of an existing image to import from, like a Dockerfile FROM; exactly one source changes - Dockerfile instructions applied to the new image, e.g. ['CMD ["/bin/sh"]']; only CMD, ENTRYPOINT, ENV, EXPOSE, ONBUILD, USER, VOLUME and WORKDIR are supported. Parsed as real Dockerfile syntax, so shell form is wrapped exactly as a Dockerfile would wrap it (CMD /bin/sh is stored as ["/bin/sh","-c","/bin/sh"]) — use the exec form CMD ["/bin/sh"] to store a bare argv returns: str - The daemon's raw newline-delimited JSON progress records; the final record carries the new image id as its status

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNo
dataNo
changesNo
from_urlNo
from_fileNo
from_imageNo
repositoryNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description is a treasure trove of behavioral details beyond the minimal annotations: it reveals that `from_url`/`from_image` are fetched by the daemon while `from_file`/`data` are local, details error conditions (ValueError, FileNotFoundError, daemon refusing digest refs), and explains the resulting image's empty config and lack of provenance labels. It also clarifies the shell form vs exec form behavior for `changes`. Annotations only state readOnlyHint:false and destructiveHint:false, which the description aligns with and enriches.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place. The description leads with a clear summary, then layers in critical caveats (distinction from image_load, empty config, single source requirement). It uses a clear 'args:' structure, bullet-like formatting for parameters, and a 'returns' line, making dense technical content scannable. Despite its length, it wastes no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 7 parameters, no required fields, multiple source options, and subtle error semantics, this description is remarkably complete. It covers parameter validation, client-vs-daemon execution, return format, and even common pitfalls (the daemon silently substituting 'latest' for blank tags). The output schema exists, but the description still explains the return format, ensuring nothing is left to guesswork.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only names and types (0% description coverage), so the description must do all the semantic work. It delivers with a dedicated 'args:' block covering all 7 parameters, including examples, defaults, error cases, and mutual exclusions. For instance, it explains that `repository` can include a tag, that `tag` overrides a tag in `repository`, and that `data` is base64-encoded by MCP. This far exceeds compensating for the schema's silence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb-resource pair ('Create an image from a flat root-filesystem tarball, like `docker import`') and immediately differentiates from the sibling `image_load` by contrasting the archive types and use cases. Distinct from the name alone and highly specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly outlines when to use this tool vs. `image_load`: 'prefer `image_load` for anything `image_save` produced. Use this for a rootfs that came from somewhere else'. Provides clear scenarios (container_export archive, distro base tarball, VM image dump) and even mentions the `changes` parameter for setting a default command. This is exemplary guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/L337-org/docker-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server