Skip to main content
Glama

image_import

Import a root-filesystem tarball as a new Docker image, with optional Dockerfile instructions. For rootfs archives from sources other than docker-save output.

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); ToolInputError 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 ToolInputError, 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 (ToolInputError without it - the daemon would otherwise silently drop the tag and import untagged). Blank is also a ToolInputError, 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; refused 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.2.5

TDQS

A5/5.0
Behavior5/5

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

With minimal annotations (only readOnlyHint=false and destructiveHint=false), the description carries the full behavioral burden and does so thoroughly. It discloses single-layer/no-history semantics, empty config unless `changes` is supplied, source-fetch differences between daemon and server, ToolInputError edge cases, tag-override behavior, and the absence of provenance labels.

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?

The description is long but tightly packed with necessary information for a 7-parameter tool with many edge cases. It is well structured: purpose and sibling differentiation first, then Args, then Returns. Every sentence serves a purpose, and the details are grouped logically rather than dumped randomly.

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?

The description covers source selection constraints, defaults, error conditions, tag handling, supported `changes` instructions, and the return format (raw NDJSON progress with the final record containing the image id). Given the tool complexity and zero schema coverage, nothing essential for correct invocation is missing.

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?

Schema description coverage is 0%, so the description must fully compensate, and it does. Every parameter gets meaningful detail: `repository` with tag/untagged semantics, `tag` override behavior, `from_file` path resolution, `data` base64 encoding, `from_url` daemon fetching, `from_image` as Dockerfile FROM, and `changes` with supported instructions and shell-form parsing.

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 opening line states a specific action and resource: 'Create an image from a flat root-filesystem tarball, like `docker import`.' It further disambiguates from `image_load` by explaining exactly what kind of archive each tool handles, so an agent can distinguish this tool from its closest sibling.

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?

The description explicitly tells when to use this tool versus alternatives: 'prefer image_load for anything image_save produced' and 'Use this for a rootfs that came from somewhere else.' It even enumerates example sources such as a `container_export` archive or distro tarball, leaving no ambiguity about selection.

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

Deploy Server

Other Tools