get_crictl_logs

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

With no annotations, the description does real work: it discloses the SSH transport, merged streams, root requirement, and the API-server-down failure mode. However, it says nothing about the SSH authentication behavior implied by key_path/password/accept_new_hostkey (auto-trusting new host keys is a security-relevant behavior), nor about timeout semantics or truncation of large output.

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-loaded with what it fetches and the SSH/remote context, followed by the sibling pointer and then parameter formats. The since-format examples are slightly verbose but each adds non-derivable syntax, so almost every sentence 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?

Return values need not be described since an output schema exists, and the tool's read-only nature is implicit. For a 10-parameter remote-SSH tool with zero annotation coverage, though, the absence of any explanation of authentication options and connection/host-key handling leaves an agent guessing on how it will actually authenticate.

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% across 10 parameters, so the description must compensate, and it does for the two least obvious ones: `lines` (count of trailing lines) and `since` (with concrete accepted formats such as '30m', '1h30m', absolute UTC). It leaves port, timeout, key_path, password, and accept_new_hostkey completely undefined, and container_id is only implied via the get_crictl_ps pointer.

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 and resource with precise scope: the last `lines` of a SPECIFIC CRI container's merged stdout/stderr, fetched over SSH from a remote Linux host. It adds the key differentiator 'Works when the API server is down', which separates it from kubectl-based siblings, and names get_crictl_ps as the way to obtain the container ID.

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 an explicit prerequisite step ('Use get_crictl_ps first to find the container ID') and an operational condition ('Works when the API server is down'), plus a permission note ('Usually requires root'). It does not explicitly exclude the docker/kubectl log siblings, so the routing is clear but not fully enumerated.

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