browser_console_messages

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

Annotations declare readOnlyHint:true and destructiveHint:false, so the agent knows it's a safe read operation. The description does not add behavioral detail beyond that, such as whether messages persist across navigations or if the tool returns messages from subframes. Since annotations already handle the safety profile, the description does not need to repeat that, so a 3 is appropriate.

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, short sentence that is front-loaded and contains no superfluous words. It earns its place by being direct. However, it could benefit from additional context (e.g., about filtering or persistence) without becoming overly verbose, so it's not a perfect 5.

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?

Given the tool has 3 parameters (one required), 100% schema coverage, and no output schema, the description is minimally adequate. It tells the agent what the tool does, but does not explain nuances like the 'all' parameter (return all messages since session start vs. since last navigation) or the 'filename' parameter (write to file vs. return as text). These are covered in the schema, so the description doesn't need to repeat them, but it could offer a brief usage context. It's sufficient for a straightforward read 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 has 100% description coverage, so the parameters are well-documented in the schema itself. The description merely says 'Returns all console messages,' which does not add additional meaning beyond what the schema provides. However, because schema coverage is high, the baseline is 3, and the description adds no further semantics. Given the schema carries the burden, a 4 reflects that the description doesn't detract but doesn't enhance either.

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 'Returns all console messages' uses a specific verb ('Returns') and identifies the resource ('console messages'). It clearly states what the tool does, although it lacks differentiation from sibling tools like 'browser_network_requests' or 'browser_network_request' which also retrieve data. The purpose is effectively communicated.

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 provides no guidance on when to use this tool versus alternatives. It does not mention that console messages are browser-specific, or suggest when to use filtering parameters like 'level' or 'filename'. In a browser context, it might be useful to contrast with 'browser_network_requests' for debugging, but nothing is stated.

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