browser_console

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

No annotations are provided, so the description carries full responsibility for disclosing behavior. It clearly explains the incremental cursor semantics, filtering options, and limit continuation behavior, which are non-obvious traits. However, it does not mention potential side effects (e.g., whether reading clears the buffer) or edge cases like invalid level values, though these may be low risk for a read-only console reader.

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 compact, information-dense single sentence with semicolon-separated clauses. Every part delivers value: purpose, filters, cursor mechanics, and limit behavior. No filler or repetition of schema fields.

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 simple console-reading tool with no annotations and no output schema, the description provides a solid understanding of what it does, its key parameters, and how to paginate. The main gap is the unexplained 'task_id' parameter, which might be relevant in multi-task contexts, and there's no mention of what happens when the console is empty or if it captures historical output. Overall, it's complete enough for an agent to use correctly.

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. It explains the meaning of 'since', 'level', 'pattern', and 'limit' with concrete usage details (regex, defaults, continuation). However, it omits 'task_id' entirely, and the list of valid level values is incomplete ('...' implies more but not enumerated), leaving some parameters under-specified.

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 states a specific verb and resource: '读取页面 console 输出' (read page console output), and clarifies the output includes level/text/location. This distinguishes it from sibling tools like browser_errors (which would be error-specific) and browser_network (which focuses on network traffic).

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 explains how to use the tool: incremental cursor behavior (since omitted vs since=0), level/pattern filtering, and limit cap with continuation advice. It doesn't explicitly compare with alternatives or state when not to use it, but the purpose is clear enough that context implies when to choose it over siblings.

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