seleniumbase-mcp

Official

Overview Schema Source Related Servers Discussions Admin

save_page

Save the current browser page as a PNG screenshot, HTML source, or PDF file to a local path for persistent artifacts. Requires a running browser session and does not modify the page.

Instructions

Save the current browser page to a local filesystem file.

Use this tool when the browser workflow needs a persistent file artifact from the current page: a PNG screenshot, the current page source as HTML, or a PDF representation of the current page.

A browser session must already be running. This tool operates on the currently active browser tab and does not navigate, click, type, or otherwise modify the webpage.

Args: format: - "screenshot": Save a PNG screenshot of the current page. - "html": Save the current page source as an HTML file. - "pdf": Save the current page as a PDF.

filename:
    Optional output filename. If omitted, defaults to:
    - "screenshot.png" for format="screenshot"
    - "page_source.html" for format="html"
    - "page.pdf" for format="pdf"

folder:
    Optional destination folder passed to SeleniumBase.
    If omitted, SeleniumBase uses its default output location.

Side effects and filesystem behavior: This tool writes a file to the filesystem and may overwrite an existing file with the same output name. Only use trusted and authorized filesystem paths. The MCP process must have permission to write to the requested destination.

The tool does not upload, publish, or transmit the saved file by
itself. The resulting file remains in the filesystem available to
the MCP server process.

Error behavior: If the browser session is not running, the tool returns a lifecycle error. Filesystem, browser, or SeleniumBase failures are converted into descriptive MCP error results by the server's error handler.

When not to use: - Do not use this tool merely to read page text or HTML; use get_content instead. - Do not use this tool when you only need page metadata such as the URL or title; use get_page_info instead. - Do not use this tool to manipulate the page; use the appropriate interaction tool such as click_element, type_text, or select_option.

Returns: A confirmation message containing the requested output format and filename after the save operation succeeds.

Input Schema

TableJSON Schema

Name	Required	Default
`folder`	No
`format`	No	screenshot
`filename`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.3.3Sep 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it discloses filesystem writes, overwrite risk, trusted-path requirement, permission needs, no upload/publish behavior, prerequisite of a running session, and error behavior. This is unusually complete for a mutation tool with zero annotation coverage.

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?

Well structured with front-loaded purpose and clearly labeled sections (Args, Side effects, Error behavior, When not to use, Returns). Slightly longer than strictly necessary, with some restatement in the error section, but every paragraph earns its place for a tool with no annotations.

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

Completeness5/5

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

Given zero annotation coverage, 0% schema description coverage, and mutation semantics, the description is complete: prerequisites, side effects, error handling, parameter behavior, and sibling routing are all covered. Output is a confirmation message, so the brief Returns note suffices even with an output schema present.

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

Parameters5/5

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, and it does: it defines the three format values, explains filename defaults per format, and clarifies that folder is passed to SeleniumBase with a stated default fallback.

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?

Starts with a specific verb+resource ('Save the current browser page to a local filesystem file') and enumerates the three output formats. Clearly distinguished from read-only siblings like get_content and get_page_info.

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

Usage Guidelines5/5

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

Provides an explicit 'when to use' trigger (persistent file artifact needed) and a 'when not to use' section that names get_content, get_page_info, click_element, type_text, and select_option with the conditions that select each. Fully routable.

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