Retrieves recent console messages and JavaScript errors from the current tab after enabling console capture with configure(capture_console=True), so you can debug page issues.
Recent console messages and JS errors of the current tab. Requires configure(capture_console=True) because CloakBrowser hides CDP console events for stealth.
| Name | Required | Description | Default |
|---|---|---|---|
| clear | No | ||
| limit | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds non-obvious behavior beyond them: console events are suppressed by the stealth layer unless capture is enabled. This is exactly the kind of hidden-state disclosure structured fields cannot convey. It says nothing about how the buffer behaves when 'clear' is set, which is the remaining transparency gap.
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, no waste: the first states scope and payload, the second states the prerequisite and the reason for it. Front-loaded correctly.
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 the capture prerequisite is covered. However, for a tool whose only two parameters are undocumented, the description leaves an agent guessing at 'clear' semantics (buffer reset vs filter) and 'limit' behavior, which is the one thing it should have added.
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% for both parameters, so the description carries the full burden and provides nothing: 'limit' (default 50) is unexplained in meaning or bounds, and 'clear' is not mentioned at all despite implying a destructive buffer reset in a tool annotated readOnlyHint=true. The description adds no meaning beyond the raw schema.
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 resource and scope: recent console messages and JS errors of the current tab. An agent can distinguish this from list_network_requests or snapshot without opening the schema. It stops short of naming a sibling it is not, so not a 5.
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 a concrete precondition: configure(capture_console=True) must be called first, and explains why (CloakBrowser hides CDP console events). That is a real routing constraint rather than vague context. It does not say when to prefer this over evaluate or list_network_requests, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.