Skip to main content
Glama

plugin_push

Push an installed Docker plugin to its registry, publishing locally built plugins. Handles authentication via Docker config and surfaces registry rejections as an error field.

Instructions

Push an installed plugin to its registry.

The write-side counterpart to plugin_install (which pulls) and the publish step after plugin_create builds a plugin locally: name must already be the registry-qualified name the plugin is installed under, since - unlike image_push - there is no plugin equivalent of image_tag to rename it first, so create it under the target name. The plugin does not need to be enabled. Credentials come from system_login, or from ~/.docker/config.json if the host ran docker login. Does NOT raise when the registry rejects the push: an authentication or quota failure arrives as a final progress record and is surfaced as the error key, so check that key rather than assuming success. Raises CapabilityError if the installed docker-py is too old to expose the internals below, and reports the daemon's own error if the plugin isn't installed.

Bypasses docker-py's Plugin.push()/APIClient.push_plugin(), which cannot work: both POST to /plugins/{name}/pull, a route the Engine does not define (push is /plugins/{name}/push), so they 404 against any daemon. Bug present since the method was written in 2017 and still in docker-py main; it survives because upstream has no test covering it. This calls the correct endpoint through docker-py's private request helpers, in the manner of system_logout's api._auth_configs reach-in, and fails loudly if those internals change shape.

Caveat for ssh:// daemons: docker-py can't cancel an SSH stream, so the timeout_seconds watchdog can't interrupt a push that stalls with the connection still open - the same limitation container_logs carries in follow mode. The call still returns normally once the registry answers or the stream ends.

Args: name: Installed plugin name to push, [registry/]author/name:tag; :latest if the tag is omitted. A bare author/name pushes to Docker Hub timeout_seconds: Max wall-clock seconds to wait on the push stream before returning what was collected (default 300); raise it for a large plugin over a slow link

Returns: dict: {"name", "progress": [], "truncated": bool, "error": str or None} - error is non-None only when the registry reported a failure

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
timeout_secondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Goes far beyond annotations (which only state readOnlyHint=false and destructiveHint=false). It discloses the non-raising behavior on registry rejection, surfaces CapabilityError for old docker-py, reports daemon errors, explains the docker-py bug and its bypass, and documents the ssh daemon timeout limitation. All these behavioral traits are transparently described.

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

Conciseness4/5

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

The description is long but every sentence earns its place, covering purpose, exceptions, caveats, parameters, and return. It is front-loaded with the core action. The only minor inefficiency is the extended explanation of the docker-py bug, though it adds value for troubleshooting. Overall well-structured and not padded.

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 2-parameter tool with no output schema, the description is fully complete. It documents the exact return dict, parameter details, error behaviors, credential requirements, and edge cases (ssh daemons, tag defaulting). An agent has everything it needs to call this tool correctly, including how to interpret the result.

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 has 0% description coverage, so the description must fully explain parameters. It details the `name` format (`[registry/]author/name:tag`, default :latest, bare author/name pushes to Docker Hub) and explains `timeout_seconds` with its default and a hint to raise it for large plugins over slow links. This exceeds compensation and provides actionable semantics.

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 clearly states the action: 'Push an installed plugin to its registry.' It distinguishes from sibling tools by naming plugin_install (the pull counterpart) and image_push (where image_tag exists). It also positions itself as the publish step after plugin_create, giving an unambiguous purpose.

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 guidance on when to use: as the opposite of plugin_install, and as the publish step after plugin_create. It explains that the name must already be registry-qualified because there's no plugin_tag, and clarifies credential requirements (system_login or docker login) and that the plugin need not be enabled. It also warns about failure reporting (check the error key). These are concrete usage conditions and alternative differentiators.

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