dokploy_docker

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

With no annotations provided, the description carries the full behavioral disclosure burden, and it does so well. It warns that writeContainerFile writes into the running container and 'the change is lost on redeploy unless the path is a mount', discloses that readContainerFile output is 'truncated at 100k chars', and equates pruneBuildCache with a specific existing dokploy_settings action. These are exactly the kind of behavioral traits an agent cannot infer from the schema.

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

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

The description is dense but every clause adds operational value, and it is organized into clear sections: containers, container files, observability, and disk. The overview is front-loaded, and even parenthetical details like default ranges and truncation limits are compact. For a tool with 17 actions, this length is warranted and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 17-action tool with no output schema and no annotations, the description is remarkably complete: parameter bindings, defaults, min/max bounds, side effects, and equivalents are all present. The main missing piece is detailed return-shape information for actions like getContainers, getConfig, and getEvents, and explicit routing against sibling tools; these are not strictly required for selection and invocation but would make it fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 55%, but the description substantially fills the gap by mapping parameters to actions: containerId+serverId for container operations, containerId+path for file operations, content for writeContainerFile, minutes with default 15, and sinceHours with max 168. It also explains the meaning of method values and the conditional requirement of type, which the schema alone does not connect to specific actions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Docker daemon management' and then enumerates exact action families: containers, files inside them, events, health, and disk usage. It names each operation with its parameters, so an agent knows precisely what resource and verb this tool exposes. The scope is distinct from sibling tools like dokploy_docker_volume and dokploy_docker_image, which target narrower resource types.

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

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

The description gives clear within-tool usage guidance, such as 'label → REQUIRES type: standalone|swarm' and 'match → fuzzy name match (optional appType...)', which helps an agent pick the right action and parameter combination. It does not explicitly say when to prefer this tool over a sibling, but the daemon-level scope and action categories make the intended context clear.

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