Skip to main content
Glama
deenesjakoruzh
ananddtyagi

Webpage Screenshot MCP Server

by ananddtyagi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

网页截图 MCP 服务器

一个使用 Puppeteer 截取网页截图的 MCP（模型上下文协议）服务器。该服务器允许 AI 代理直观地验证 Web 应用程序，并在生成 Web 应用程序时查看其进度。

屏幕录制 2025年5月27日 (2)

特征

  • 全页面截图：捕获整个网页或仅捕获视口

  • 元素截图：使用 CSS 选择器定位特定元素

  • 多种格式：支持 PNG、JPEG 和 WebP 格式

  • 可定制选项：设置视口大小、图像质量、等待条件和延迟

  • Base64 编码：将屏幕截图以 Base64 编码图像的形式返回，以便于集成

  • 身份验证支持：手动登录和cookie持久化

  • 默认浏览器集成：使用系统的默认浏览器获得更自然的体验

  • 会话持久性：保持浏览器会话处于打开状态以进行多步骤工作流

Related MCP server: MCP Browser Screenshot Server

安装

# Install globally
npm install -g screenshot-webpage-mcp

# Or use locally in a project
npm install screenshot-webpage-mcp

用法

工具

该 MCP 服务器提供了几种工具：

1. 登录并等待

在可见的浏览器窗口中打开网页进行手动登录，等待用户完成登录，然后保存 cookie。

{
  "url": "https://example.com/login",
  "waitMinutes": 5,
  "successIndicator": ".dashboard-welcome",
  "useDefaultBrowser": true
}

  • url （必填）：登录页面的 URL

  • waitMinutes （可选）：等待登录的最大分钟数（默认值：5）

  • successIndicator （可选）：指示登录成功的 CSS 选择器或 URL 模式

  • useDefaultBrowser （可选）：是否使用系统默认浏览器（默认值：true）

2. 屏幕截图

捕获给定 URL 的屏幕截图并将其作为 base64 编码图像返回。

{
  "url": "https://example.com/dashboard",
  "fullPage": true,
  "width": 1920,
  "height": 1080,
  "format": "png",
  "quality": 80,
  "waitFor": "networkidle2",
  "delay": 500,
  "useSavedAuth": true,
  "reuseAuthPage": true,
  "useDefaultBrowser": true,
  "visibleBrowser": true
}

  • url （必填）：需要截图的网页地址

  • fullPage （可选）：是否捕获整个页面或仅捕获视口（默认值：true）

  • width （可选）：视口宽度（以像素为单位）（默认值：1920）

  • height （可选）：视口高度（以像素为单位）（默认值：1080）

  • format （可选）：图像格式 - “png”、“jpeg”或“webp”（默认：“png”）

  • quality （可选）：图像质量（0-100），仅适用于 jpeg 和 webp

  • waitFor （可选）：何时考虑页面加载 - “load”、“domcontentloaded”、“networkidle0”或“networkidle2”（默认值：“networkidle2”）

  • delay （可选）：页面加载后的额外延迟（以毫秒为单位）（默认值：0）

  • useSavedAuth （可选）：是否使用上次登录时保存的 cookie（默认值：true）

  • reuseAuthPage （可选）：是否使用现有的认证页面（默认值：false）

  • useDefaultBrowser （可选）：是否使用系统默认浏览器（默认值：false）

  • visibleBrowser （可选）：是否显示浏览器窗口（默认值：false）

3. 屏幕截图元素

使用 CSS 选择器捕获网页上特定元素的屏幕截图。

{
  "url": "https://example.com/dashboard",
  "selector": ".user-profile",
  "waitForSelector": true,
  "format": "png",
  "quality": 80,
  "padding": 10,
  "useSavedAuth": true,
  "useDefaultBrowser": true,
  "visibleBrowser": true
}

  • url （必填）：网页的 URL

  • selector （必需）：要截图的元素的 CSS 选择器

  • waitForSelector （可选）：是否等待选择器出现（默认值：true）

  • format （可选）：图像格式 - “png”、“jpeg”或“webp”（默认：“png”）

  • quality （可选）：图像质量（0-100），仅适用于 jpeg 和 webp

  • padding （可选）：元素周围的填充（以像素为单位）（默认值：0）

  • useSavedAuth （可选）：是否使用上次登录时保存的 cookie（默认值：true）

  • useDefaultBrowser （可选）：是否使用系统默认浏览器（默认值：false）

  • visibleBrowser （可选）：是否显示浏览器窗口（默认值：false）

4. 清除身份验证 cookie

清除特定域或所有域的已保存身份验证 cookie。

{
  "url": "https://example.com"
}

  • url （可选）：需要清除 Cookie 的域名 URL。若未提供，则清除所有 Cookie。

默认浏览器模式

默认浏览器模式允许您使用系统自带的浏览器（Chrome、Edge 等），而不是 Puppeteer 自带的 Chromium 浏览器。此功能适用于：

  1. 使用现有的浏览器会话和扩展程序

  2. 使用已保存的凭据手动登录网站

  3. 为多步骤工作流程提供更自然的浏览体验

  4. 使用与用户相同的浏览器环境进行测试

要启用默认浏览器模式，请在工具参数中设置useDefaultBrowser: true和visibleBrowser: true 。

默认浏览器模式的工作原理

启用默认浏览器模式时：

  1. 该工具将尝试找到系统的默认浏览器（Chrome、Edge 等）

  2. 它会启动你的浏览器，并在随机端口上启用远程调试

  3. Puppeteer 连接到此浏览器实例，而不是启动自己的

  4. 您现有的配置文件、扩展程序和 Cookie 在会话期间可用

  5. 浏览器窗口仍然可见，因此您可以手动与其交互

此模式对于需要身份验证或复杂用户交互的工作流特别有用。

浏览器持久性

MCP 服务器可以在多个工具调用之间维持持久的浏览器会话：

  1. 当您使用login-and-wait时，浏览器会话保持打开状态

  2. 后续使用reuseAuthPage: true调用screenshot-page或screenshot-element将使用同一页面

  3. 这允许多步骤工作流程，而无需重新进行身份验证

Cookie 管理

您访问的每个域名都会自动保存 Cookie：

  1. 使用login-and-wait后，cookie 将保存到主文件夹中的.mcp-screenshot-cookies目录中

  2. 当使用useSavedAuth: true再次访问同一域时，会自动加载这些 cookie

  3. 您可以使用clear-auth-cookies工具清除 cookies

示例工作流程：受保护的页面截图

以下是对需要身份验证的页面进行截图的示例工作流程：

  1. 手动登录阶段

{
  "name": "login-and-wait",
  "parameters": {
    "url": "https://example.com/login",
    "waitMinutes": 3,
    "successIndicator": ".dashboard-welcome",
    "useDefaultBrowser": true
  }
}

这将打开您的默认浏览器并显示登录页面。您可以手动登录。登录完成后（无论是检测到登录成功指示，还是离开登录页面），会话 Cookie 都会被保存。

  1. 使用已保存的会话截取屏幕截图

{
  "name": "screenshot-page",
  "parameters": {
    "url": "https://example.com/account",
    "fullPage": true,
    "useSavedAuth": true,
    "reuseAuthPage": true,
    "useDefaultBrowser": true,
    "visibleBrowser": true
  }
}

这将在同一浏览器窗口中使用您保存的身份验证 cookie 截取帐户页面的屏幕截图。

  1. 截取特定元素的屏幕截图

{
  "name": "screenshot-element",
  "parameters": {
    "url": "https://example.com/dashboard",
    "selector": ".user-profile-section",
    "useSavedAuth": true,
    "useDefaultBrowser": true,
    "visibleBrowser": true
  }
}

  1. 完成后清除 Cookies

{
  "name": "clear-auth-cookies",
  "parameters": {
    "url": "https://example.com"
  }
}

此工作流程允许您像普通用户一样与受保护的页面进行交互，并在默认浏览器中完成完整的身份验证流程。

无头模式与可见模式

  • 无头模式（ visibleBrowser: false ）：更快，更适合不需要用户交互的自动化工作流程。

  • 可见模式( visibleBrowser: true )：显示浏览器窗口，允许用户交互和手动验证。 useDefaultBrowser: true时必需。

平台支持

默认浏览器检测适用于：

  • macOS ：检测 Chrome、Edge 和 Safari

  • Windows ：通过注册表或常见安装路径检测 Chrome 和 Edge

  • Linux ：通过系统命令检测 Chrome 和 Chromium

故障排除

常见问题

  1. 未找到默认浏览器：如果系统找不到您的默认浏览器，它将恢复使用 Puppeteer 捆绑的 Chromium。

  2. 连接问题：如果连接到浏览器的调试端口时出现问题，请检查是否有另一个实例正在使用该端口。

  3. Cookie 问题：如果身份验证不起作用，请尝试使用clear-auth-cookies工具清除 cookie。

调试

出现问题时，MCP 服务器会将有用的错误消息记录到控制台。查看这些消息以获取故障排除信息。

Available Tools

5 tools
clear-auth-cookiesA

Clears saved authentication cookies for a specific domain or all domains

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoURL of the domain to clear cookies for. If not provided, clears all cookies.

TDQS

A3.7/5.0
Behavior2/5

Does 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 action ('clears saved authentication cookies') but does not disclose behavioral traits such as whether this requires specific permissions, if it's reversible, potential side effects (e.g., logging out users), or rate limits. The description is minimal and lacks critical context for a mutation tool.

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 zero waste, front-loading the core action and scope. It is appropriately sized for a simple tool with one optional parameter.

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

Completeness3/5

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

Given the tool's complexity (simple mutation with one parameter) and lack of annotations or output schema, the description is adequate but has clear gaps. It covers the basic purpose and parameter semantics via the schema, but fails to provide behavioral context needed for safe usage, such as permissions or side effects.

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%, with the parameter 'url' documented as 'URL of the domain to clear cookies for. If not provided, clears all cookies.' The description adds no additional meaning beyond this, as it only restates the same information. Baseline 3 is appropriate when the schema does the heavy lifting.

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 clearly states the tool's purpose with a specific verb ('clears') and resource ('saved authentication cookies'), and distinguishes its scope ('for a specific domain or all domains'). It directly answers what the tool does without being vague or tautological.

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

Usage Guidelines4/5

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

The description implies usage context by specifying 'for a specific domain or all domains,' but does not explicitly state when to use this tool versus alternatives or provide exclusions. Given the sibling tools (e.g., 'login-and-wait'), it lacks guidance on when to clear cookies relative to login/logout workflows.

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

login-and-waitA

Opens a webpage in a visible browser window for manual login, waits for user to complete login, then saves cookies

ParametersJSON Schema
NameRequiredDescriptionDefault
successIndicatorNoOptional CSS selector or URL pattern that indicates successful login
urlYesThe URL of the login page
useDefaultBrowserNoWhether to use the system's default browser instead of Puppeteer's bundled Chromium
waitMinutesNoMaximum minutes to wait for login (default: 3)

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's behavior well: opening a visible browser, waiting for manual login, and saving cookies. However, it misses details like error handling, what happens after timeout, or how cookies are saved/stored. It does not contradict annotations, as none exist.

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 that front-loads the core purpose and steps. Every word earns its place, with no redundancy or unnecessary details, making it highly concise and well-structured.

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

Completeness3/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 adequately covers the tool's purpose and high-level behavior. However, for a tool with 4 parameters and no output schema, it lacks details on return values, error cases, or integration with sibling tools like 'signal-login-complete'. It's complete enough for basic understanding but has gaps for full contextual use.

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 the schema fully documents all parameters. The description does not add any parameter-specific information beyond what the schema provides (e.g., it doesn't explain 'successIndicator' usage or 'waitMinutes' implications). Baseline 3 is appropriate as the schema handles the heavy lifting.

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 clearly states the specific action sequence: 'Opens a webpage in a visible browser window for manual login, waits for user to complete login, then saves cookies.' It uses precise verbs (opens, waits, saves) and identifies the resource (webpage, cookies), distinguishing it from sibling tools like screenshot tools or cookie-clearing tools.

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

Usage Guidelines4/5

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

The description implies usage for manual login scenarios where user interaction is required, but it does not explicitly state when to use this tool versus alternatives like automated login tools or other authentication methods. It provides clear context (manual login in a browser) but lacks explicit exclusions or named alternatives.

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

screenshot-elementB

Captures a screenshot of a specific element on a webpage using a CSS selector

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNoImage format for the screenshotpng
paddingNoPadding around the element in pixels
qualityNoQuality of the image (0-100), only applicable for jpeg and webp
selectorYesCSS selector for the element to screenshot
urlYesThe URL of the webpage
useDefaultBrowserNoWhether to use the system's default browser instead of Puppeteer's bundled Chromium
useSavedAuthNoWhether to use saved cookies from previous login
visibleBrowserNoWhether to show the browser window (non-headless mode)
waitForSelectorNoWhether to wait for the selector to appear

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic function. It doesn't disclose important behavioral traits like: whether this navigates to new URLs, requires page loading, handles authentication, has rate limits, or what happens with invalid selectors. The description is minimal beyond the core action.

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?

Single sentence, zero waste words, front-loaded with the core action. Every word earns its place by specifying element-level capture with CSS selector mechanism.

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?

For a 9-parameter tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (image data? file path? error formats?), doesn't mention authentication dependencies despite sibling login tools, and provides minimal behavioral context for a complex screenshot operation.

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 the schema fully documents all 9 parameters. The description adds no parameter-specific information beyond implying 'selector' and 'url' are involved. Baseline 3 is appropriate when schema does all parameter documentation work.

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 clearly states the specific action ('Captures a screenshot') and target resource ('specific element on a webpage'), using precise terminology ('CSS selector'). It distinguishes from sibling 'screenshot-page' by specifying element-level rather than page-level capture.

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 explicit guidance on when to use this tool versus alternatives like 'screenshot-page' or other siblings. The description implies usage for element-specific screenshots but doesn't provide context about prerequisites (e.g., needing authentication via login tools) or exclusions.

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

screenshot-pageA

Captures a screenshot of a given URL and returns it as base64 encoded image. Can use saved cookies from login-and-wait.

ParametersJSON Schema
NameRequiredDescriptionDefault
delayNoAdditional delay in milliseconds to wait after page load
formatNoImage format for the screenshotpng
fullPageNoWhether to capture the full page or just the viewport
heightNoViewport height in pixels
qualityNoQuality of the image (0-100), only applicable for jpeg and webp
reuseAuthPageNoWhether to use the existing authenticated page instead of creating a new one
urlYesThe URL of the webpage to screenshot
useDefaultBrowserNoWhether to use the system's default browser instead of Puppeteer's bundled Chromium
useSavedAuthNoWhether to use saved cookies from previous login
visibleBrowserNoWhether to show the browser window (non-headless mode)
waitForNoWhen to consider the page loadednetworkidle2
widthNoViewport width in pixels

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the ability to use saved cookies, which hints at authentication behavior, but doesn't cover other important traits like performance implications (e.g., page load delays), potential failures (e.g., invalid URLs), or side effects (e.g., browser resource usage). The description adds some value but leaves significant gaps for a tool with 12 parameters.

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, well-structured sentence that efficiently conveys the core functionality and a key feature (cookie reuse). Every word earns its place with no redundancy or fluff, making it appropriately sized and front-loaded.

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

Completeness3/5

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

Given the tool's complexity (12 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and authentication context but lacks details on behavioral traits, error handling, or output specifics (beyond base64 encoding). For a screenshot tool with many configuration options, more guidance on usage scenarios or limitations would be helpful.

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 the schema already documents all 12 parameters thoroughly. The description adds minimal semantic context by mentioning 'saved cookies from login-and-wait,' which loosely relates to the 'useSavedAuth' parameter, but doesn't provide additional meaning beyond what the schema specifies for most parameters. Baseline 3 is appropriate when the schema does the heavy lifting.

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 clearly states the specific action ('captures a screenshot') and resource ('of a given URL'), and distinguishes from sibling tools by mentioning the ability to use saved cookies from 'login-and-wait' (differentiating from 'screenshot-element' which targets specific elements). It also specifies the output format ('returns it as base64 encoded image').

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

Usage Guidelines4/5

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

The description provides clear context by mentioning saved cookies from 'login-and-wait', which implies when to use this tool (for authenticated pages). However, it doesn't explicitly state when NOT to use it or name alternatives like 'screenshot-element' for element-specific captures, leaving some guidance implicit rather than explicit.

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

signal-login-completeA

Signals that manual login is complete and the login-and-wait tool should continue

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It describes the behavioral trait of signaling completion to another tool, which is useful context. However, it doesn't disclose other aspects like whether it requires specific permissions, has side effects, or how it interacts with authentication states, leaving some gaps.

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 that front-loads the key information: signaling login completion. There is zero waste, and it earns its place by clearly stating the tool's role in the workflow.

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

Completeness4/5

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

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is complete enough. It explains the purpose and usage in context with sibling tools. However, it could be slightly more complete by mentioning any prerequisites or effects, but for a signaling tool, this is adequate.

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

Parameters4/5

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but this is acceptable given the lack of parameters. Baseline is 4 for 0 params, as it doesn't need to compensate for any gaps.

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 tool's purpose: to signal completion of manual login so another tool (login-and-wait) can continue. It specifies the verb 'signals' and the context 'manual login is complete,' but doesn't explicitly differentiate from all sibling tools like clear-auth-cookies or screenshot tools, which serve different purposes.

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?

The description explicitly states when to use this tool: 'when manual login is complete' and that it should be used to allow 'login-and-wait tool should continue.' It names the specific alternative tool (login-and-wait) and implies usage in a sequence, providing clear context without exclusions.

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. 5 tool updatesv1.0.0
    • First observedclear-auth-cookies
    • First observedlogin-and-wait
    • First observedscreenshot-element
    • First observedscreenshot-page
    • First observedsignal-login-complete
Deploy Server
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

TDQS

A3.7/5.0

Scored across 5 tools

Disambiguation4/5

Most tools have distinct purposes: screenshot-element and screenshot-page target different screenshot scopes, while login-and-wait and clear-auth-cookies handle authentication. However, signal-login-complete is tightly coupled with login-and-wait, which could cause confusion about whether to use it separately or as part of the login flow.

Naming Consistency3/5

The naming is mixed: screenshot-element and screenshot-page follow a verb-noun pattern, but clear-auth-cookies and login-and-wait use hyphens and compound phrases, while signal-login-complete is a full sentence. This inconsistency makes the set less predictable, though the names remain readable.

Tool Count5/5

With 5 tools, the count is well-scoped for a webpage screenshot server. Each tool serves a clear role in the workflow (authentication, screenshot capture, and cleanup), and there are no extraneous tools, making it efficient for agents to navigate.

Completeness4/5

The toolset covers core screenshot and authentication workflows effectively, including login, cookie management, and element/page capture. A minor gap is the lack of tools for advanced screenshot options (e.g., full-page capture or viewport adjustments), but agents can still accomplish the main tasks without significant workarounds.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches