exec_container

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

Annotations are entirely absent, so the description carries the full burden of behavioral disclosure. It reveals that a command is executed in a running container but says nothing about side effects, whether output or exit codes are returned, or how the interactive parameter affects behavior. For an arbitrary-command execution tool, this is under-disclosed.

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 a single efficient sentence with no filler and the core action front-loaded. It is appropriately concise, though it sacrifices behavioral context that other dimensions require.

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 tool that executes arbitrary commands, the description is thin: it omits return behavior, the semantics of interactive mode, caution about destructive effects, and explicit disambiguation from sibling tools. With no annotations and no output schema, this leaves an agent under-informed about the consequences of calling the tool.

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?

The input schema describes all three parameters with 100% coverage, so the baseline is 3. The description adds marginal context by specifying the container is already running, but it does not add meaning to command or interactive beyond the 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?

The description states a clear verb and resource: execute a command in a running container. It distinguishes itself from run_container and compose_up because it implies the container already exists, but it does not explicitly name alternatives.

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?

There is no guidance about when to use this tool versus run_container, container_logs, or inspect_container. The phrase 'running container' implies the prerequisite that the container must already be active, but no explicit when-to-use or when-not-to-use direction is provided.

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