Skip to main content
Glama

buildx_imagetools_create

Combine per-platform image tags into a single multi-arch manifest list and push it in one operation.

Instructions

Create a manifest list / OCI image index from existing per-platform tags.

Replaces docker manifest create + docker manifest push — builds the index and pushes it in one operation. Source tags must already be pushed; this only stitches them together. Verify the result with buildx_imagetools_inspect. Does not raise on a non-zero CLI exit — inspect returncode/stderr in the result.

args: target - Tag for the new manifest list (-t) sources - Source image references to combine append - Append to the existing manifest at target rather than replacing dry_run - Print the resulting manifest without pushing annotations - OCI annotations (repeatable; passed verbatim) platforms - Filter source platforms when combining descriptor_files - Files to read source descriptors from, instead of refs (copied to the target host if no local plugin) builder - Override the active builder timeout_seconds - Subprocess timeout (default 600s) returns: dict - {"returncode": int, "stdout": str, "stderr": str, "truncated": bool}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appendNo
targetYes
builderNo
dry_runNo
sourcesYes
platformsNo
annotationsNo
timeout_secondsNo
descriptor_filesNo
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses a key behavioral quirk: 'Does not raise on a non-zero CLI exit — inspect returncode/stderr in the result.' It also states the operation builds and pushes in one step, adding valuable context for error handling.

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 well-structured: a terse summary, a short context paragraph, and a clean arg list. No wasted sentences; all content adds value. The front-loaded summary and scannable parameter list make it easy to parse.

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?

With 9 parameters and no output schema, the description fully covers the tool's operation: prerequisites, side effects, return format, and even error behavior. It also explains advanced parameters like descriptor_files. This is complete for an agent to invoke correctly.

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 coverage is 0%, so the description must compensate. It does so comprehensively: every parameter is listed with a meaningful explanation (e.g., 'append - Append to the existing manifest at target rather than replacing'). This adds semantics far beyond the bare schema.

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 first sentence clearly states the verb and resource: 'Create a manifest list / OCI image index from existing per-platform tags.' It distinguishes itself from sibling tools like buildx_imagetools_inspect (verification) and buildx_build (building), and even references the legacy docker command it replaces.

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?

Provides explicit context: source tags must already be pushed, and this tool only stitches them together. It also recommends verifying with buildx_imagetools_inspect, giving the user a clear workflow and alternative. This fully satisfies the when-to-use and next-steps 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