Console log

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

The stealth-mode caveat is exactly the kind of non-obvious behavioral disclosure that annotations cannot convey, and it is the strongest part of the definition. However, annotations only say readOnlyHint=false, and the description never mentions that `action=clear` is a destructive, non-reversible operation that mutates captured state — the single most important behavior for this tool to disclose.

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?

Two sentences, zero filler, with the core purpose front-loaded and the caveat correctly demoted to a note. Nothing could be cut without losing information.

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?

No output schema and near-zero annotation coverage mean the description must carry more weight, and it covers the environment gotcha well. But for a four-parameter tool it omits the destructive `clear` action, the meaning of `filter`, and any sense of return shape or volume (the 300 cap), leaving real gaps for an agent to guess at.

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% across four parameters, so the description carries the full burden and adds essentially nothing: `filter` is never explained (filter by message text? by source?), `limit` and its 300 cap are unmentioned, and `level` semantics are left to the enum. The only parameter-like reference, `engine=chromium`, is not even a property in this tool's schema, which risks confusing the agent about what it can pass here.

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: 'Read console messages and page errors captured since launch.' The scope ('captured since launch') is precise and no sibling tool covers console output, so it is distinguishable. It stops short of naming a sibling or contrasting with the adjacent `network` / `evaluate` tools.

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 one genuine usage conditional: 'use engine=chromium when console output matters', which tells the agent when this tool will return nothing useful. Beyond that there is no when-to-use guidance, no explanation of when to choose `action=clear` versus `action=list`, and no mention of when to reach for a different tool.

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