Skip to main content
Glama
tech-lead-bunny

agenteyes-mcp

by tech-lead-bunny
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

agenteyes-mcp

A Node.js MCP server (stdio transport) exposing agent tools backed by headless Chromium. One tool call returns screenshot PNG(s), an accessibility snapshot, and page text — eyes for agents.

Requirements

  • Node.js 20+

  • On first install, Playwright downloads the Chromium headless shell (postinstall script)

Related MCP server: rasterly-mcp

Install and run

npx agenteyes-mcp@0.1.0

Or from a clone:

git clone https://github.com/tech-lead-bunny/agenteyes-mcp.git
cd agenteyes-mcp
npm install
node index.js

The process speaks MCP over stdio; connect it from an MCP host (Claude Desktop, Cursor, etc.).

Tools

Tool

Description

screenshot_url

Open a public http/https URL; return PNG screenshot(s), accessibility tree, and visible text

get_page_text

Same page context without screenshots (title, a11y, text)

screenshot_url parameters

  • url (required) — public http(s) URL

  • full_page (optional, default false) — capture full scroll height

  • segment_height (optional, default 0) — when full_page is true and the page is taller than this value, capture stacked viewport PNGs of this height (top to bottom), then one combined accessibility + text block

  • width / height (optional) — viewport size (defaults 1280×720)

Security (SSRF)

URLs are checked before navigation and again on the final URL after redirects:

  • Only http: and https:

  • DNS resolution must not point at private/local addresses (localhost, loopback, RFC1918, link-local 169.254.0.0/16, fe80::/10, ::1, IPv4-mapped IPv6, etc.)

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "agenteyes": {
      "command": "npx",
      "args": ["-y", "agenteyes-mcp@0.1.0"]
    }
  }
}

Cursor

In Cursor Settings → MCP, add a stdio server:

{
  "mcpServers": {
    "agenteyes": {
      "command": "npx",
      "args": ["-y", "agenteyes-mcp@0.1.0"]
    }
  }
}

Or use a local path after npm install in this repo:

{
  "mcpServers": {
    "agenteyes": {
      "command": "node",
      "args": ["/absolute/path/to/agenteyes-mcp/index.js"]
    }
  }
}

Example prompt

Use the screenshot_url tool on https://example.com with full_page: true. Summarize the page title and main message from the returned text, and describe what you see in the screenshot.

Limits (v0)

  • No hosted API — run the MCP server locally (or wherever your host spawns it)

  • No authentication or rate limiting in the server itself

  • Public URLs only — private networks and metadata endpoints are blocked

  • Chromium only — no Firefox/WebKit; no persistent login sessions between calls

  • One browser process, one page per tool call — pages are always closed after each call

  • Best-effort rendering — heavy SPAs, infinite scroll, or bot blocking may produce incomplete captures

  • Segmented full-page capture returns multiple PNGs (not a single stitched image)

MCP registry

  • mcp.so — primary listing target; submission to the registry is planned once 0.1.0 is on npm.

  • awesome-mcp — PR to add agenteyes-mcp planned the same week as the npm publish.

License

MIT — see LICENSE.

Available Tools

2 tools
get_page_textA

Open a URL in headless Chromium and return the page title, accessibility snapshot, and visible text (no screenshot).

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic http(s) URL to open in headless Chromium

TDQS

A4/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 usefully discloses the rendering path (headless Chromium) and what is omitted (no screenshot), but says nothing about JS execution, load/wait behavior, timeouts, network restrictions, or whether the fetch is read-only and side-effect free.

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?

A single front-loaded sentence with zero filler: verb, mechanism, and return payload in order of importance. Every clause earns its place.

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?

With no output schema, the description correctly enumerates the return fields (title, accessibility snapshot, visible text), which is the key missing structured information. It is complete enough to invoke correctly, though behavioral context like timeouts and JS handling is absent.

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% for the single url parameter, and the description adds no format or syntax detail beyond what the schema already states (public http(s) URL). Baseline 3 applies 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?

States a specific verb (open), resource (URL), rendering mechanism (headless Chromium), and exactly what is returned (title, accessibility snapshot, visible text). The parenthetical '(no screenshot)' explicitly distinguishes it from the sibling screenshot_url.

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 '(no screenshot)' clause effectively tells the agent when to pick this over screenshot_url, i.e. when textual/page content is wanted rather than an image. However it never names the sibling or states a positive selection condition, so the routing is implied rather than explicit.

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

screenshot_urlB

Open a URL in headless Chromium and return PNG screenshot(s), an accessibility snapshot, and visible page text.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesPublic http(s) URL to open in headless Chromium
widthNoViewport width in pixels
heightNoViewport height in pixels (ignored per segment when segmented full_page capture runs)
full_pageNoCapture the full scrollable page height instead of the viewport only
segment_heightNoWhen full_page is true and content exceeds this height (px), capture stacked viewport screenshots of this height

TDQS

B3.2/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 behavioral burden. It usefully discloses the rendering engine (headless Chromium) and the multi-artifact return shape, but says nothing about failure modes, timeouts, redirect handling, or authentication constraints beyond the schema's 'Public http(s) URL' hint.

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?

A single front-loaded sentence naming the action and the outputs, with no filler. It is appropriately sized, though the terse artifact list leaves room that brief scoping language could have used productively.

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?

With no output schema and no annotations, the description must cover both behavior and returns; it names the three return types, which helps, but omits error behavior and how its text output relates to get_page_text. Adequate but with clear gaps for a 5-parameter rendering 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% and each of the five parameters is documented in the schema, including the interaction between full_page and segment_height. The description adds no parameter detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource (open a URL in headless Chromium) and enumerates the three return artifacts, which is concrete and informative. It does not differentiate itself from the sibling get_page_text even though it admits to returning visible page text — the overlap is left for the agent to resolve.

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 on when to use this versus get_page_text, despite a clear overlap in returned content. No mention of prerequisites such as network access, target reachability, or suitability for rendering-heavy pages.

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. 2 tool updatesv0.1.0
    • First observedget_page_text
    • First observedscreenshot_url
Deploy Server
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

TDQS

B3.4/5.0

Scored across 2 tools

Disambiguation4/5

The two tools are mostly distinct: screenshot_url includes screenshots, while get_page_text does not. However, both return accessibility snapshots and visible text, creating some overlap that could lead to arbitrary selection when only text/snapshot is needed.

Naming Consistency3/5

Both names use snake_case, but verb patterns are inconsistent: 'screenshot' acts as a verb/noun, while 'get_page_text' uses the verb 'get'. The mix is readable but not a predictable pattern.

Tool Count3/5

Two tools is thin for a web content extraction service. While each tool has a role, the surface feels minimal and could benefit from additional focused tools (e.g., raw HTML, links).

Completeness3/5

Core capabilities (screenshot and text/snapshot) are covered, but notable gaps exist: no way to retrieve raw HTML, page links, or interact with the page. Agents may hit dead ends for structured data extraction.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • webshot-mcp

    Brandon-35
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables agents to take screenshots and extract text from web pages using a persistent Chrome browser via CDP, with built-in SSRF protection.
    9 npm
    MIT

  • rasterly-mcp

    rasterly-dev
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to read, screenshot, or convert web pages to PDF using a real headless browser, turning any URL into clean Markdown, a visual image, or a print-ready document.
    82 npm
    MIT
  • URLpipe MCP server by URLpipe

    URLpipe MCP serverofficial

    URLpipe
    A
    license
    Not graded
    quality
    B
    maintenance
    Gives AI agents a hosted browser that renders JavaScript, returning Markdown, screenshots, metadata, console errors, and Lighthouse audits for any URL.
    MIT