SeleniumBase MCP

Official

Overview Schema Source Related Servers Discussions Admin

Save Page

save_page

Capture the active browser tab as a PNG screenshot, HTML source, or PDF file. Persist the current page to a local file for archival or further processing.

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.

Addedv4.54.3Sep 13, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations are sparse (only readOnlyHint=false, openWorldHint=false, idempotentHint=false), so the description carries the full burden. It discloses that the tool writes files, may overwrite, requires filesystem permissions, does not modify the page, does not upload/publish, and details error behavior. It also specifies prerequisites like an active browser session.

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

Conciseness5/5

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

The description is well-organized with clear sections, bullet lists, and front-loaded purpose. Every sentence adds value—prerequisites, side effects, error handling, and alternatives—without redundancy. It is appropriately sized for the complexity of the tool.

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?

It covers prerequisites (browser session running), operational scope (does not navigate or modify), side effects (file write/overwrite), error handling, and return value. It also distinguishes from sibling tools. Given the output schema exists, the description needn't detail return structure, but it does anyway.

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 is the only source of parameter meaning. It explains each parameter (format with enum values and defaults, filename with format-dependent defaults, folder with default behavior) clearly and completely.

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?

The description opens with a precise verb and resource: 'Save the current browser page to a local filesystem file' and enumerates the exact formats (screenshot, html, pdf). It also explicitly contrasts with siblings like get_content and get_page_info, making selection unambiguous.

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?

It states exactly when to use this tool ('when the browser workflow needs a persistent file artifact') and provides a dedicated 'When not to use' section naming three alternative tools with the conditions that route to them. This is explicit and actionable.

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