dokploy_network

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

With no annotations provided, the description carries the behavioral burden. It discloses that inspect returns the raw Docker inspect payload and that recreate drops and re-adds the network, causing brief disconnection for attached services. It also clarifies the tracked-vs-untracked distinction for networksToSync. It could go further by stating whether remove deletes the Docker network or only removes it from Dokploy tracking, and by describing return shapes for list/get, but the most consequential side effects are covered.

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 efficiently organized by action type, with the 'Docker network management.' lead-in establishing scope immediately. It packs all action-parameter mappings, behavioral caveats, and cross-tool guidance into a compact set of sentences with no filler. The final cross-tool note is high-value and earns its place.

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?

Given the tool's complexity—12 parameters, 8 actions, nested IPAM object, no output schema, and no annotations—the description is notably complete. It covers every action, the parameters each action needs, a destructive side effect, and the relationship between networksToSync and import. Minor gaps remain around the exact return values for list/get/remove and the precise semantics of remove, but nothing essential blocks correct tool selection or invocation.

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 description coverage is only 33%, so the description must compensate, and it does. It maps actions to their relevant parameters, lists the create-specific parameters (driver bridge|overlay, internal, attachable, enableIPv4, enableIPv6, mtu 68-65535, ipam, serverId), and explains that import takes 'names (one or more names from networksToSync)'. This gives the agent actionable parameter semantics that the bare schema does not provide.

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 network management' and enumerates eight discrete actions: list, get, inspect, remove, recreate, create, networksToSync, and import. It specifies the resource types each acts on (serverId-scoped lists, networkId-scoped operations, names for import) and even distinguishes itself by pointing to dokploy_application/dokploy_compose for attaching networks, which separates it cleanly from sibling tools.

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 maps each action to the exact parameter it needs: serverId for list/networksToSync/import, networkId for get/inspect/remove/recreate, and names for import. It explains when networksToSync is relevant ('networks that exist on the Docker host but are not yet tracked by Dokploy') and explicitly routes attachment work to sibling tools with 'Attach networks to workloads with dokploy_application update networkIds, or dokploy_compose update serviceNetworks.'

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