Skip to main content
Glama
rogerheykoop

Safari Screenshot MCP Server

by rogerheykoop

Safari Screenshot

A Node.js MCP Server for capturing screenshots using Safari on macOS.

Features

  • Capture window screenshots at specific sizes

  • Support for different zoom levels

  • Configurable wait times for page load

  • Clean up after capture

  • Native macOS screenshot quality

Related MCP server: Website Screenshot MCP

Usage

import { takeScreenshot } from './screenshot.js';

// Basic window screenshot
await takeScreenshot({
	url: 'https://www.apple.com',
	outputPath: './screenshot.png',
	width: 1024, // Optional: window width (default: 1024)
	height: 768, // Optional: window height (default: 768)
	waitTime: 3, // Optional: seconds to wait for load (default: 3)
	zoomLevel: 1, // Optional: page zoom level (default: 1)
});

// Responsive design testing
await takeScreenshot({
	url: 'https://www.apple.com',
	outputPath: './mobile.png',
	width: 375, // iPhone SE width
	height: 667, // iPhone SE height
	zoomLevel: 1,
});

// High-resolution capture
await takeScreenshot({
	url: 'https://www.apple.com',
	outputPath: './desktop-hd.png',
	width: 1920, // Full HD width
	height: 1080, // Full HD height
	waitTime: 5, // Wait longer for HD content
	zoomLevel: 0.8, // Zoom out slightly
});

Requirements

  • macOS

  • Safari

  • Node.js >= 14.0.0

  • Terminal needs Accessibility permissions (System Preferences → Security & Privacy → Privacy → Accessibility)

Installation

npm install safari-screenshot

Options

Option

Type

Default

Description

url

string

required

The URL to capture

outputPath

string

auto

Where to save the screenshot (default: ./screenshots/[hostname]-[timestamp].png)

width

number

1024

Window width in pixels

height

number

768

Window height in pixels

waitTime

number

3

Seconds to wait for page load

zoomLevel

number

1

Page zoom level (1 = 100%)

Common Viewport Sizes

The module is tested with these common viewport sizes:

  • Desktop: 1920×1080 (Full HD)

  • Laptop: 1366×768

  • Tablet Landscape: 1024×768

  • Tablet Portrait: 768×1024

  • Mobile Large: 428×926 (iPhone 12 Pro Max)

  • Mobile Medium: 390×844 (iPhone 12 Pro)

  • Mobile Small: 375×667 (iPhone SE)

How It Works

  1. Opens Safari with specified window size

  2. Loads the URL and waits for page load

  3. Applies zoom level if specified

  4. Uses native macOS screencapture for pixel-perfect results

  5. Verifies screenshot was captured successfully

  6. Cleans up Safari windows

Permissions

This package requires System Events permissions to work:

  1. Open System Preferences > Security & Privacy > Privacy > Accessibility

  2. Add Terminal (or your IDE) to the list of allowed apps

Using with Cursor

Setup in Cursor

  1. Open Cursor

  2. Go to settings, "Add MCP Server"

  3. In the configuration dialog:

    • Name: safari-screenshot

    • Type: command

    • Command: npx -y @rogerheykoop/mcp-safari-screenshot

    Or for local development:

    • Command: npx -y /path/to/mcp-safari-screenshot/server.js

Example Commands

After connecting to the server in Cursor, you can use these commands:

Take a screenshot of https://apple.com at desktop size

Response: Will capture at 1920×1080

Capture https://apple.com on iPhone 12 Pro

Response: Will capture at 390×844

Screenshot github.com at 50% zoom

Response: Will capture with zoomLevel: 0.5

Supported Parameters

The MCP server understands these concepts:

  • Device names (e.g., "iPhone", "iPad", "desktop")

  • Dimensions (e.g., "1024x768")

  • Zoom levels (e.g., "50% zoom", "2x zoom")

  • Wait times (e.g., "wait 5 seconds")

Example Workflows

  1. Responsive Testing

    Take screenshots of apple.com on iPhone, iPad, and desktop
  2. Zoom Testing

    Capture github.com at 75% zoom and 125% zoom
  3. Custom Size

    Screenshot example.com at 1440x900

Tips

  • Screenshots are saved to the screenshots directory by default

  • Device names automatically set appropriate dimensions

  • The server handles cleanup of Safari windows

  • Use "wait X seconds" for slow-loading pages

Troubleshooting

If you encounter issues:

  1. Check Terminal has Accessibility permissions

  2. Verify Safari is not in private browsing mode

  3. Ensure the working directory is writable

  4. Check Cursor's console for error messages

License

MIT

Testing Locally

You can test the MCP implementation directly:

# Test discovery
echo '{"type":"discover"}' | npx -y ./server.js

# Test screenshot
echo '{"type":"execute","tool":"take_screenshot","input":"Take a screenshot of https://apple.com","requestId":"123"}' | npx -y ./server.js

Expected responses:

  1. Discover will return capabilities

  2. Execute will:

    • Log progress to stderr

    • Return result JSON to stdout

    • Save screenshot to ./screenshots/

Available Tools

1 tool
take_screenshotC

Take a screenshot of a webpage using Safari on macOS

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL to capture
outputPathNoPath where the screenshot will be saved (default: ./screenshots/[hostname]-[timestamp].png)
widthNoWindow width in pixels (default: 1024)
heightNoWindow height in pixels (default: 768)
waitTimeNoTime to wait for page load in seconds (default: 3)
zoomLevelNoZoom level (1 = 100%, 0.5 = 50%, 2 = 200%)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only mentions the action and environment. It lacks details on permissions needed, file system impact, error handling, or rate limits, leaving behavioral gaps for a tool that saves files.

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 a single, efficient sentence with no wasted words, clearly front-loading the core functionality. It's appropriately sized for the tool's complexity.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure, file path) or address potential issues like network errors or file permissions, which are critical for a screenshot tool.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no extra parameter meaning beyond implying URL capture, aligning with the baseline for high schema coverage.

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

Purpose4/5

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

The description clearly states the action ('take a screenshot') and target resource ('webpage'), specifying the browser ('Safari') and platform ('macOS'). It's specific but lacks sibling differentiation since no sibling tools are provided, preventing a perfect score.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as other screenshot methods or tools for different browsers/platforms. The description states what it does but offers no context for selection.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • First observedtake_screenshot

TDQS

B3.1/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is singular and clearly defined, making it impossible for an agent to misselect between non-existent alternatives.

Naming Consistency5/5

A single tool inherently has perfect naming consistency as there are no other tools to compare against. The name 'take_screenshot' follows a clear verb_noun pattern, which would be consistent if more tools existed.

Tool Count2/5

One tool is too few for most server purposes, as it severely limits functionality and scope. While it matches the server's name, a single screenshot tool feels thin and incomplete for a broader screenshot or browser automation domain.

Completeness2/5

The tool surface is severely incomplete for a screenshot server. There are obvious gaps such as no options for different screenshot types (e.g., full-page, element-specific), no configuration settings, and no related operations like listing or managing screenshots.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • -
    license
    A
    quality
    Not graded
    maintenance
    A server that provides AI assistants programmatic control of Safari browser on macOS for web automation, testing, and debugging.
    16
    1
    -
  • A
    license
    C
    quality
    D
    maintenance
    Enables taking screenshots of web pages with support for multiple devices (desktop, mobile, tablet), custom dimensions, full-page capture, and various image formats. Built with Playwright for reliable web page rendering and screenshot generation.
    1
    MIT