Skip to main content
Glama
Sign In
zenpilot

zenpilot

by beSaif
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

read_console

Retrieve console messages and uncaught page errors, oldest first, with optional level filtering, result limits, and clearing after reading to debug live browser sessions.

Instructions

Console messages and uncaught errors the page logged, oldest first, up to limit (max 200).

Only what the current page logged while zenpilot was connected: the list empties when the tab
navigates, and zenpilot disconnects after 2 minutes without tool calls, so messages from before
that are gone. Messages from iframes aren't included. Long messages are cut, and the oldest go
first if the output is too long. level shows one level only. clear empties the tab's list after reading it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "read_console"
  }
}

Input Schema

NameRequiredDescriptionDefault
clearNo
levelNo
limitNo
tab_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses retention (list empties on navigation, zenpilot disconnects after 2 minutes idle so older messages are gone), iframe exclusion, message truncation, oldest-first eviction when output is too long, and that clear destroys the buffer after reading. Gaps remain around default tab selection and behavior when disconnected, which are the only major undisclosed traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then a second paragraph of constraints; no sentence is filler. Minor density cost: the truncation sentence conflates two different behaviors (long messages cut vs. oldest dropped), and "messages from before that" is slightly ambiguous in its antecedent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Behavioral coverage is strong for a no-annotation tool, but with no output schema the description should sketch the return shape (per-entry fields such as level/text/timestamp) and it never does. tab_id semantics and the disconnected/error case are also unaddressed, so an agent knows what it will get conceptually but not structurally.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it gives real meaning to three of four parameters: limit (cap of 200, oldest dropped first), level (single level only, not multi-select), and clear (empties the tab's list after reading, i.e. destructive on the source buffer). tab_id is never mentioned, leaving the agent to guess whether it defaults to the active tab.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Console messages and uncaught errors the page logged" states a specific resource and scope, and the ordering/limit contract is given up front. No sibling (read_page, get_text, screenshot) overlaps, so the agent can select it unambiguously.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: it's the tool for inspecting page console output, and the retention constraints hint at when reads must happen promptly. However, there is no explicit when-to-use/when-not guidance nor a pointer to alternatives such as get_text or read_page for DOM content, and no statement of prerequisites (page must be connected).

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

Deploy Server

Other Tools