Skip to main content
Glama

swarm_leave

Destructive

Leave the current Docker swarm and reschedule service tasks to remaining nodes. Force mode lets managers exit without breaking raft quorum.

Instructions

Leave the current swarm.

The daemon's service tasks are rescheduled to the remaining nodes. A manager refuses to leave without force=True, since leaving can break raft quorum. The departed node lingers as "down" in node_list until a manager runs node_remove.

Args: force: Force leave even if the node is a manager

Returns: bool: True after leaving the swarm

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the destructiveHint and readOnlyHint annotations, the description reveals key behavioral details: service tasks are rescheduled, managers refuse without force due to raft quorum risk, and the departed node remains 'down' until node_remove is invoked. These details materially help an agent anticipate consequences.

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 front-loaded with the core action, then adds dense, relevant behavioral details. The Args and Returns sections are clean and non-redundant, and every sentence earns its place by explaining consequences or parameter behavior.

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?

The description covers the operation, the force parameter, manager-specific behavior, quorum risk, service rescheduling, and post-leave node state. There is nothing an agent needs to correctly call this tool and anticipate its effects that 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 carries the full burden for the force parameter. It explains both the semantic meaning ('Force leave even if the node is a manager') and the behavioral consequence of leaving force=False, making the single parameter fully actionable.

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 'Leave the current swarm,' which is a specific verb+resource statement that immediately distinguishes this tool from swarm_init, swarm_join, swarm_update, and swarm_inspect. It also clarifies the scope of the operation, so an agent can tell exactly what the tool does.

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

Usage Guidelines3/5

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

The description gives clear context for when the tool is used and the special condition for managers (force=True), but it does not explicitly state when to prefer this tool over alternatives or mention sibling tools. Usage is implied rather than explicitly contrasted with swarm_join or swarm_update.

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