Skip to main content
Glama
L337-org

docker-mcp-server

by L337-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

plugin_create

Build a Docker plugin from a local plugin data directory and install it under a specified name. Use for self-built plugins when you have config.json and rootfs locally; the plugin is created disabled, ready for configuration and activation.

Instructions

Build a plugin from a local plugin data directory and install it under name.

The counterpart to plugin_install, which pulls an already-published plugin from a registry: use this only for a plugin rootfs you built yourself, and plugin_install for anything on a registry. plugin_data_dir is read on the machine running this server (not on the daemon host), must already contain a config.json manifest and a rootfs directory, and is tarred client-side and posted to the daemon - in a container it must be a bind mount or the path resolves to nothing. The new plugin is created disabled: call plugin_configure for any settings it declares, then plugin_enable to activate it. Raises if the directory is missing or lacks config.json/rootfs, or if name is already installed (remove it first with plugin_remove). Unlike the other create tools, this stamps no provenance labels - the Engine API's plugin-create call accepts none.

Args: name: Local name for the plugin, author/name:tag; the :latest tag is optional and is the default if omitted plugin_data_dir: Path on this server's filesystem to the plugin data directory (containing config.json and rootfs) gzip: Compress the uploaded directory with gzip

Returns: dict: The created plugin's full document ({"Id", "Name", "Enabled", "Settings", "Config"})

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gzipNo
nameYes
plugin_data_dirYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A5/5.0
Behavior5/5

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

Annotations only state readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It discloses that the new plugin is created disabled, that plugin_data_dir is read on the server rather than the daemon host, that the path must resolve to a bind mount in a container, and that the tool raises on missing directories or already-installed names. This far exceeds what annotations alone convey.

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 substantial but every sentence earns its place: scoping, operational details, failure modes, workflow, argument semantics, and return type. It is front-loaded with the core purpose and structured with Args/Returns sections, making the dense information 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?

For a three-parameter mutation tool with no output schema, the description covers all required operational context: client-side taring, server-vs-daemon path semantics, bind-mount caveat, disabled-by-default state, error conditions, collision handling, and the exact return document shape. Nothing an agent needs to call this correctly 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?

With 0% schema description coverage, the description must fully document parameters, and it does: name gets its author/name:tag format plus the optional default :latest tag, plugin_data_dir gets both its filesystem location and required contents, and gzip gets its compression behavior. This adds real meaning beyond the bare schema types.

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 specific verb-resource pair: 'Build a plugin from a local plugin data directory and install it under name.' It immediately distinguishes this tool from plugin_install by naming the counterpart and the exact condition that selects each, so an agent can tell them apart without inspecting schemas.

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?

Usage guidance is explicit: use this only for a plugin rootfs you built yourself, and plugin_install for anything on a registry. It also prescribes the follow-up workflow (plugin_configure then plugin_enable), the prerequisite removal of an existing plugin name, and the container bind-mount requirement, leaving no ambiguity about when or how to invoke it.

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