Analyze the current page to extract structured data like title, URL, text, inputs, buttons, links, menus, and console errors—ideal for understanding page content without screenshots.
Analyze current page and return structured information: title, url, text, inputs, buttons, links, menus and recent console errors. Use this instead of screenshot when you only need to understand the page.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is non-mutating (analyze) and lists the return data, but does not disclose potential caveats like whether it waits for page load, truncates large text, or affects console error state. The description is adequate but lacks deeper behavioral detail beyond what is already implied.
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 two sentences, with the core action and returned data front-loaded, followed by a practical usage pointer. Every word contributes value; there is no fluff or repetition. It is an exemplar of concise, structured tool documentation.
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 no parameters and no output schema, the description sufficiently explains what the agent will receive and when to use it. It does not mention potential prerequisites like ensuring the page is loaded, but the sibling set includes browser_wait_human and browser_open, which could be inferred. For a simple analysis tool, the description is largely complete.
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 tool has zero parameters, so the description does not need to explain any. The schema already reflects no inputs, and the description adds no parameter-specific information, which is appropriate. Baseline for 0 params is 4, and the description correctly omits parameter details.
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 clearly states the tool's action ('Analyze current page') and specifies the structured information returned (title, url, text, inputs, buttons, links, menus, console errors). It explicitly differentiates from the sibling browser_screenshot by advising when to use it instead, making its unique purpose unmistakable.
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 explicit guidance: 'Use this instead of screenshot when you only need to understand the page.' This directly addresses the most likely alternative. However, it does not mention other overlapping tools like browser_text or browser_elements, though the listed return fields implicitly suggest coverage. The guidance is clear for the primary alternative but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.