Skip to main content
Glama

image_tag

Assign a tag to a local Docker image to create an alias for registry-qualified naming, enabling subsequent push operations.

Instructions

Tag an image into a repository (add a name to an existing local image).

The image id stays the same and no data is copied — a tag is an alias. Typical flow: tag with the registry-qualified name, then image_push. image_remove on a tag merely untags while other names remain.

args: id_or_name - The source image name or id repository - Target repository name (registry-qualified for pushing, e.g. "ghcr.io/o/r") tag - Optional tag for the new image (default "latest") force - Force the tag returns: bool - True if the image was tagged

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagNo
forceNo
id_or_nameYes
repositoryYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Annotations already indicate non-read-only and non-destructive, but description adds that the image id stays the same, no data is copied, and returns a bool. Adds useful behavioral nuance beyond annotations.

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?

Description is concise, well-structured with clear sections. First sentence summarizes purpose, then flow, then parameter list. No unnecessary 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?

Given low complexity and existence of output schema (bool), description covers usage, parameters, return, and relation to siblings. Provides a complete picture for an agent.

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%, but description fully explains each parameter: id_or_name, repository with example, tag with default 'latest', force. Adds meaning and default value not in 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?

Clearly states the tool tags an image by adding a name to an existing local image. Distinguishes from siblings like image_push and image_remove by explaining the typical flow and the effect of removal.

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

Usage Guidelines4/5

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

Provides explicit guidance: tag is an alias, no data copied, typical flow is tag then push. Mentions that image_remove merely untags. Lacks explicit when-not-to-use but covers key points.

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/GavinLucas/docker-mcp'

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