Skip to main content
Glama

swarm_task_inspect

Read-only

Get full details of a single Docker Swarm task by ID, unique prefix, or name. Use it to inspect or troubleshoot a specific task after listing tasks or viewing service events.

Instructions

Inspect a single swarm task, like docker inspect --type task.

For when you already hold a task reference -- from a swarm_task_list or service_ps row, a service event, or an error message -- and want just that task. swarm_task_list returns the same document for every task, so prefer it when scanning; this is the single-object fetch. To reach the container behind a running task, read Status.ContainerStatus.ContainerID and pass it to container_inspect / container_logs -- but note the container may be on another node, where those tools cannot see it, and service_logs aggregates across tasks instead. Read-only. Requires a swarm manager; raises docker.errors.APIError if the task does not exist, if a prefix matches more than one task, or if this node is not a manager.

args: id_or_name - The task id, an unambiguous id prefix, or the task's full name -- which is the container-name form <service>.<slot>.<taskid> (<service>.<nodeid>.<taskid> for a global service), NOT the shorter <service>.<slot> that docker service ps prints in its NAME column, which does not resolve. The daemon tries full id, then full name, then prefix, and rejects an ambiguous prefix rather than picking a match returns: dict - Full task inspect payload, as docker inspect --type task. Carries no name field of its own; compose one from ServiceID/Slot if you need it

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
id_or_nameYes
Behavior5/5

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

Beyond the annotations readOnlyHint=true and destructiveHint=false, the description adds meaningful behavioral context: it is read-only, requires a swarm manager, and raises `docker.errors.APIError` when the task does not exist, when a prefix is ambiguous, or when the node is not a manager. It also explains the daemon's resolution order for ids and names. No contradiction with annotations.

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 organized into clear paragraphs and explicit `args` / `returns` sections. It is long but every sentence provides actionable guidance or necessary caveats, with no wasted repetition. The clarity and structure enable accurate tool invocation.

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?

Given one simple string parameter, no output schema, and the subtle Docker swarm name-resolution behavior, the description is thorough enough to support correct invocation. It covers the single-task purpose, return payload shape, required manager authority, error conditions, and caveats about accessing the underlying container across nodes.

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?

Even though schema description coverage is 0%, the description fully compensates by thoroughly explaining `id_or_name`: it covers valid id prefixes, full name form `<service>.<slot>.<taskid>`, the global-service variant, the trap that `docker service ps` NAME column does not resolve, and the daemon's fallback order plus ambiguity rejection. This is far beyond the bare schema.

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 tool inspects a single swarm task, using the docker CLI analogy `docker inspect --type task` and explicitly distinguishes it from `swarm_task_list` as the single-object fetch. The verb-resource pairing is unambiguous and differentiates 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.

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: when the agent already holds a task reference and wants only that task. It also names alternatives and exclusions: prefer `swarm_task_list` when scanning, use `container_inspect`/`container_logs` to reach containers with caveats, and use `service_logs` for cross-task logs. It additionally states the prerequisite of a swarm manager.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/L337-org/docker-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server