list_pods

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

Annotations already declare readOnlyHint=true, so the '[READ]' tag is redundant. The description earns credit beyond that by disclosing the failure mode on unsupported targets and the underlying libpod API, which an agent needs to interpret errors correctly.

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?

Front-loads the verb and resource, then adds the Podman-only caveat and argument note. The middle explanatory sentence is slightly long but each part informs correct invocation, so little is wasted.

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?

With no output schema, the description compensates by listing the returned fields. Combined with the target requirement and error behavior, an agent has everything needed to call the tool and interpret results.

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 0%, so the description must carry the burden, and it does: it explains that 'target' is a config target name and that omitting it uses the default. That resolves the parameter's meaning and default behavior not present in the bare schema.

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?

States a specific verb + resource (List Podman pods) and enumerates the returned fields (id, name, status, member containers). It also distinguishes itself from the Docker-oriented siblings by flagging the Podman-native concept and the absence of a Docker equivalent.

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?

Gives a clear precondition ('Requires a podman target') and an explicit when-not condition (on docker/portainer it returns a teaching error). It does not, however, name a concrete alternative tool for non-podman targets, so it falls short of full routing guidance.

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