Run a command

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

The description discloses significant behavioral traits beyond the annotations: it explains the output filtering mechanism (only relevant lines shown, gaps quantified), the persistence of full output on disk, the re-sending of results with the transcript, and the integration with `peek` for retrieving arbitrary ranges. It also clarifies the `keep` parameter's behavior. This exceeds what annotations (readOnlyHint=false, destructiveHint=true) already convey and does not contradict them.

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 well-structured and front-loaded: it states the core purpose first, then explains the mechanism, then gives usage guidance. Every sentence adds value—there is no filler or repetition. Despite its length, it remains dense and useful, prioritizing the most critical information for an agent deciding whether and how to call the tool.

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 with six parameters and no schema descriptions, the description is incomplete. It covers the output-handling behavior thoroughly but leaves the semantics of `cwd`, `timeout`, `background`, and `budget` unspecified. An agent cannot fully understand the tool's capabilities or constraints without additional inference. The presence of an output schema helps with return values, but parameter completeness is still lacking.

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 description coverage is 0%, so the description must compensate for all six parameters. It provides detailed semantics for `keep` ('every line containing it comes back whatever else was chosen') and mentions `peek` with a returned handle, but it says nothing about `cwd`, `timeout`, `background`, or `budget`. This leaves a large gap in parameter understanding, especially for a tool with destructive potential.

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 clearly states a specific verb and resource: 'Run a shell command and return only the lines that mattered.' It distinguishes itself from a generic shell tool by emphasizing filtered output, and it names the sibling 'peek' as a companion. However, it does not directly differentiate itself from the listed siblings (follow, outline, digest, tool, digest_many), relying instead on the general notion of a 'plain shell tool'.

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?

The description gives explicit guidance: 'Prefer this over a plain shell tool whenever the output may be long or noisy.' It also provides a concrete usage pattern: 'When you already know what you are looking for -- a symbol, a test name, an error code -- pass it as `keep`.' This tells the agent when to use the tool and how to tailor its invocation, leaving little to inference.

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