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

Annotations already declare readOnlyHint and destructiveHint=false, and the description confirms with 'It changes nothing' while adding traits annotations cannot: newest-first ordering, a hard cap of 10, field parity with the getter, and a safety warning that `question` text is untrusted website content. The untrusted-content warning is genuinely valuable behavioral context; pagination or cursor behavior past the 10-item cap is not addressed.

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 the core purpose and cap, then parameters, then workspace routing in a separate paragraph that cleanly separates the credentials concern. Slightly long for a list tool, but no sentence is filler — the injection warning and routing rule both carry weight.

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?

Output schema exists, so return values need no explanation, and annotations cover the safety profile. The description nonetheless adds the missing pieces an agent needs: ordering, the 10-item cap, field parity, workspace resolution rules, and the untrusted-text warning.

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 100% and every parameter is already documented, so baseline is 3. The description's parameter sentences largely restate the schema ('open_only for the questions that still take an answer', workspace_id behavior) without adding syntax, defaults or edge cases beyond what the schema states.

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 together with scope, ordering and cap: 'List the questions your own browser tasks asked you in this workspace, newest first, at most 10'. It also pins the row shape by reference ('same fields as well_get_browser_action_ask'), so an agent can distinguish it from the single-item getter without opening either schema.

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 concrete when-to-use conditions per parameter ('Pass browser_action_id for the questions of one task, and open_only for the questions that still take an answer') and a workspace routing rule: call directly on a single-workspace token, pass workspace_id when several are authorized. It never explicitly contrasts itself with the sibling single-ask getter or the Claude-code-session equivalent, so it falls short of the exclusive when/when-not/alternative framing.

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