Read the session's recent page console output (log/info/warn/error) as {url, total, messages:[{ts_ms, level, text}]}, newest last. Ring buffer of 500 entries; captures output from page scripts, clicks, evals and navigation alike. The fastest way to see WHY a page misbehaves: click the button, call this, read the error.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe-read behavior is established. The description adds valuable behavioral context beyond that: the 500-entry ring buffer, newest-last ordering, and the fact it captures output from multiple execution paths. It does not discuss edge cases or retention timing, which keeps it from being a 5.
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 three sentences with no wasted content: the first defines the operation and output contract, the second adds buffer capacity and scope, and the third gives a concrete use-case. It is front-loaded and every sentence earns its place.
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 one-parameter read-only tool with no output schema, the description adequately covers what an agent needs: the output object shape, ordering, buffer size, and which actions are captured. The parameter is fully documented by the schema, and the annotation covers safety. No critical calling context is missing.
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?
Parameter schema coverage is 100%, and the only parameter is session_id, already documented as 'Session ID'. The description confirms the output is session-related but does not add any new semantic meaning about the parameter itself. This is the baseline 3 case where the schema carries the parameter-documentation burden.
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 read operation with a clear resource: it reads the session's recent page console output and lists the exact output shape. It makes the console-read domain clear, and the capture coverage across scripts, clicks, evals, and navigation helps distinguish it from sibling tools. It does not explicitly name or contrast any sibling tool, so it misses the top score for explicit differentiation.
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 final sentence gives an explicit use case: call this to see why a page misbehaves. It also implies broad applicability by saying the output comes from page scripts, clicks, evals, and navigation alike. No alternatives or 'when not to use' guidance are provided, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes, but there's overlap between session_click/click and session_eval/eval. Descriptions clarify that session_* tools operate on persistent sessions while the others are one-off, so ambiguity is low.
The session_* prefix is consistently used for session-related tools (17 of 23), while the remaining tools (cache, click, download, eval, fetch, search) are single-word lowercase verbs. This is a clear pattern, though not strictly verb_noun.
23 tools is above the typical 3-15 range but reasonable for a browser automation server that needs both one-off and session-based operations. The count is justified by the breadth of features, though it's slightly heavy.
The surface covers all major browser automation needs: navigation, clicking, typing, scrolling, screenshot, state inspection, console/network logs, cookies/storage management, JavaScript eval, waiting, and even session export. No obvious gaps for the stated purpose.