What can you do with this server?

The visual-inspector-mcp server enables AI agents to see and interact with real web pages through a persistent headless Chromium browser session, preserving login state, scroll position, and client-side SPA state across calls. * Navigate to URLs — Load any URL (local dev server, file://, or public site) in a persistent browser instance. * Take screenshots — Capture the page as PNG or JPEG, scoped to a specific element (via CSS selector), the viewport, or the full scrollable page. * Click elements — Simulate clicks to reach UI states (e.g., open modals, menus, or tabs) before screenshotting. * Fill form fields — Set values on inputs, textareas, and selects, dispatching events React controlled components need; supports batch-filling multiple fields in one call. * Type per-keystroke — Simulate typing one character at a time (firing keydown/keypress/keyup per character) for inputs that require real keystroke events. * Press keyboard keys — Send keys like Enter, Tab, Escape, or combos like Control+A to a specific or currently focused element. * Resize the viewport — Change browser dimensions to test responsive breakpoints without reloading or losing client-side state. * Retrieve console logs — Fetch recent browser console messages and page errors, with options to filter to errors only, limit count, and include timestamps.

How do I use visual-inspector-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@visual-inspector-mcp Navigate to https://example.com and take a screenshot" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

visual-inspector-mcp

by MatinMHF

Overview Schema Related Servers Score Discussions

JavaScript

Local

visual-inspector-mcp

npm version License: MIT Node

English | فارسی

An MCP server that lets Claude Code — or any MCP-compatible client — actually see and interact with the web pages it's working on, instead of only reading the source. It runs a persistent headless Chromium browser (via Playwright) and returns screenshots as inline images the model can view directly in the tool result.

"This icon looks wrong" → the agent screenshots the icon and looks at it, instead of guessing from the CSS.

Why

Coding agents are excellent at reading and writing code, but blind to what that code actually renders as. A misaligned icon, a color that doesn't match the design, a responsive layout that breaks at a certain width, a modal that overlaps its own close button — none of these are visible from source alone. This server closes that gap with a set of small, composable tools built around a single persistent browser session — including full form interaction, so the agent can fill inputs, type keystrokes, and submit forms before looking at the result.

Related MCP server: Browser MCP

Tools

Tool	Description
`navigate`	Load a URL (dev server, `file://`, or any public site) in a persistent page. Stays open for subsequent calls. Returns the resolved URL + title, so silent redirects are visible.
`screenshot`	Screenshot the current page, or a single element by CSS selector / Playwright locator syntax (e.g. `text=Submit`). Supports viewport, full-page, and element-scoped capture. Defaults to lossless PNG; JPEG is an opt-in for large, photo-heavy full-page captures.
`click`	Click an element to reach a UI state (open a modal, menu, tab) before screenshotting it.
`fill`	Set the value of an input/textarea/select by selector (`locator.fill` — clears then types, dispatching the input/change events React controlled components need). Pass `fields` to fill several inputs in one call.
`type`	Type into a field one key at a time (`locator.pressSequentially`), firing a keydown/keypress/keyup per character — for inputs whose handlers need real keystrokes and don't react to `fill`. Optional `clear` and per-keystroke `delay`.
`press`	Press a keyboard key such as `Enter` (submit a form), `Tab`, or `Escape`, against a given `selector` or the focused element. Supports Playwright key syntax (e.g. `Control+A`).
`resize`	Change the viewport size to check a responsive breakpoint, independent of navigating or screenshotting — so you can resize → click → screenshot without reloading the page (and losing client-side state).
`console_logs`	Recent browser console messages and page errors, to correlate a visual issue with a JS error. Supports `limit` and an `error`-only filter.

Full parameter reference is in the tool descriptions themselves (visible to any MCP client) and in index.js.

Requirements

Node.js 18 or later
~200 MB free disk space (Playwright downloads a Chromium build on install)

Installation

git clone https://github.com/MatinMHF/visual-inspector-mcp.git
cd visual-inspector-mcp
npm install        # installs dependencies and downloads Chromium via postinstall

Configuration

Claude Code

claude mcp add --scope user visual-inspector -- node /absolute/path/to/visual-inspector-mcp/index.js

--scope user registers it for every project. Use --scope project instead to scope it to the current repo, or omit --scope for the current session only. Restart Claude Code (or start a new session) after adding it — a running session won't pick up a newly registered server.

On Windows PowerShell, quote the -- separator:

claude mcp add --scope user visual-inspector "--" node "C:/path/to/visual-inspector-mcp/index.js"

Verify it's connected:

claude mcp list

Claude Desktop (or any client using `claude_desktop_config.json`)

Add to your claude_desktop_config.json:

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

Other MCP clients

This is a standard stdio MCP server — node index.js speaks MCP over stdin/stdout. Any client that supports stdio-transport MCP servers can run it the same way.

Usage

Once configured, just ask naturally:

"Navigate to localhost:3000/settings and screenshot the save icon in the toolbar — does it look right?"

"Resize to 375x667 and check what the mobile nav looks like after I click the hamburger menu."

"Fill in the signup form with test data and submit it — any errors?"

"Any console errors on the checkout page?"

Typical tool sequences:

// Visual inspection
navigate({ url: "http://localhost:3000/settings" })
screenshot({ selector: "#save-icon" })   // isolate just the element
console_logs({ level: "error" })         // check for related JS errors

// Form interaction
navigate({ url: "http://localhost:3000/signup" })
fill({ fields: [{ selector: "#name", value: "Ada" }, { selector: "#email", value: "ada@example.com" }] })
press({ key: "Enter", selector: "[type=submit]" })
screenshot({})                           // see the result

// Responsive check
resize({ width: 375, height: 667 })
screenshot({ fullPage: true })

Design notes

One persistent page per server process. navigate doesn't spin up a new browser each call — it reuses the same page/context so state (login, scroll position, SPA client state) survives across click → fill → screenshot sequences.
fill vs type. fill is almost always the right choice — it clears the field, sets the value atomically, and fires the input/change events React's controlled components need. Use type only when the input's handler specifically reacts to individual keystrokes (e.g. an autocomplete that fires on keydown).
Cheapest-capture-first. screenshot's tool description actively steers the calling model toward selector (one element) over the default viewport, and viewport over fullPage (most expensive in image tokens).
Lossless by default. Screenshots are PNG unless you explicitly opt into format: "jpeg". On flat-color UI (icons, buttons), JPEG is often no smaller — so PNG stays the default; on photo-heavy full-page captures, JPEG at quality 80 measured ~75–80% smaller in testing.
Bounded log output. console_logs defaults to the last 30 entries with no timestamps — pass limit/withTimestamps for more.

Security note

This server gives the connected AI client the ability to navigate a real (headless) browser to any URL it's given — including localhost and other addresses on your local network. It's designed to run locally over stdio for trusted development use, the same way you'd trust any other local dev tooling. Don't expose it over a network transport or hand it to an untrusted client.

Development

npm test        # runs smoke-test.mjs: spins up the server as a subprocess and
                # exercises every tool + parameter over the real MCP protocol

smoke-test.mjs is also run in CI on every push/PR (see .github/workflows/test.yml).

Changelog

v1.1.0

Added fill tool — set input/textarea/select values (supports batch fields[])
Added type tool — per-keystroke typing for inputs needing real keydown events
Added press tool — send keyboard keys (Enter, Tab, Escape, Control+A, …)
Extended smoke test with full form interaction coverage

v1.0.0

Initial release: navigate, screenshot, click, resize, console_logs

License

MIT

Available Tools

8 tools

clickClickA

Click an element by selector to reach a UI state (open a menu/modal/tab) before screenshotting it.

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	CSS selector or Playwright locator of the element to click

TDQS

A4/5.0

Behavior3/5

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

Annotations show readOnlyHint=false, which is consistent with the description's implication of state change. The description adds minimal behavioral context beyond annotations (e.g., 'reach a UI state'), but lacks details like what happens on failure or if the page navigates.

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 of 16 words. Every word contributes to the purpose, and it is front-loaded with the verb and resource.

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?

For a simple tool with one parameter and no output schema, the description adequately covers the tool's purpose and context of use. However, it omits details about error handling or post-click behavior, which might be useful for reliability.

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 coverage is 100%, so the schema already documents the selector parameter. The description adds no additional meaning beyond restating 'by selector', which does not compensate for the lack of parameter elaboration.

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 action (click), the resource (element by selector), and the purpose (reach a UI state before screenshotting). It distinguishes from sibling tools like navigate and screenshot by specifying the context of use.

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 implicitly guides usage by stating 'before screenshotting', indicating the tool is for preparing UI states for screenshots. However, it does not explicitly mention when not to use it or suggest alternatives for other actions.

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

console_logsConsole logsA

Read-only

Recent browser console messages and page errors — correlate a visual issue with a JS error.

ParametersJSON Schema

Name	Required	Description
`clear`	No	Clear the buffer after reading
`level`	No	'all' (default) or 'error' (errors, page errors, and warnings only)
`limit`	No	Max entries to return, most recent first (default 30)
`withTimestamps`	No	Include timestamps in the output (default false)

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is a safe read operation. The description adds value by specifying the content (console messages and page errors) and the suggested use case (correlating with JS errors). It discloses that logs are recent but does not elaborate on buffer behavior beyond the clear parameter.

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, front-loaded sentence that conveys the purpose and a key use case without any unnecessary words. It efficiently communicates the tool's function.

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 no output schema, the description clarifies the type of data returned (console messages and page errors). Combined with well-documented parameters, the description is largely complete for a read-only tool. A minor gap is the lack of explicit mention of the browser context, but it is implied.

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?

The input schema provides 100% coverage for all four parameters with descriptions. The tool description does not add extra meaning beyond the schema, so baseline score of 3 is appropriate.

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 returns 'recent browser console messages and page errors' and provides a specific use case: 'correlate a visual issue with a JS error'. It distinguishes itself from sibling tools like click, navigate, which are actions, and screenshot, which is a visual capture, by focusing on logs.

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

Usage Guidelines3/5

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

The description implies usage for debugging visual issues but does not provide explicit instructions on when to use this tool versus alternatives, nor does it mention when not to use it. It lacks direct guidance for an AI agent to choose among siblings.

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

fillFill form fieldA

Set the value of an input/textarea/select by selector (Playwright locator.fill — clears then types, and dispatches the input/change events React controlled components need). Pass fields to fill several inputs in one call. Use type instead only for inputs that require per-keystroke keydown events.

ParametersJSON Schema

Name	Required	Description
`value`	No	Value to set for `selector`
`fields`	No	Fill multiple fields in order, e.g. [{selector, value}, ...]
`selector`	No	CSS selector or Playwright locator of a single field to fill

TDQS

A4.2/5.0

Behavior4/5

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

Annotations only state not read-only and not destructive. Description adds key behavioral traits: clears then types, dispatches input/change events for React controlled components. This is valuable context beyond annotations.

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?

Two sentences with no wasted words. Purpose is front-loaded, and key details are efficiently conveyed.

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?

No output schema exists, but the description covers the core behavior, parameter options, and alternative tool usage. Sufficient for an agent to understand when and how to use this 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 coverage is 100% with descriptions. The description elaborates on 'fields' usage and explains the fill behavior (clears then types) but does not add significant detail for each parameter beyond the schema.

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 it sets the value of form fields via Playwright locator.fill, specifying input/textarea/select. It distinguishes from the sibling 'type' tool by noting when to use type instead.

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?

Provides explicit guidance: 'Use `type` instead only for inputs that require per-keystroke keydown events.' Also mentions using 'fields' for multiple inputs. Lacks explicit 'when not to use' but clearly differentiates from sibling.

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

navigateNavigateA

Load a URL in a persistent headless browser page (dev server, file://, or public site). Stays open for later click/screenshot calls.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL to load
`waitForSelector`	No	Wait for this selector before returning (SPAs)

TDQS

A4.4/5.0

Behavior4/5

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

The description adds transparency beyond annotations by noting the page persists for later interactions. Annotations do not mention persistence, so this is valuable. However, error handling or limitations (e.g., invalid URLs) are not disclosed.

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 concise, consisting of two sentences with the core action first. Every sentence adds value without redundancy or fluff.

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?

The description is adequate for this simple tool, covering the main behavior and persistence. It could be improved by mentioning return value or error scenarios, but given no output schema and low complexity, it is fairly complete.

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?

While schema descriptions cover both parameters (url and waitForSelector), the tool description adds context about valid URL types (dev server, file://, public site) and implies persistence, enhancing understanding beyond the schema.

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: to load a URL in a persistent headless browser page. It specifies the types of URLs supported (dev server, file://, public site) and distinguishes itself from sibling tools like click, screenshot, etc., which are subsequent actions.

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 context on when to use this tool, mentioning it stays open for later click/screenshot calls. However, it does not explicitly exclude alternatives or state when not to use it, missing some guidance for selection among siblings.

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

pressPress keyA

Press a keyboard key such as 'Enter' (submit a form), 'Tab', or 'Escape'. With selector the key is sent to that element; without it, to the focused element. Supports Playwright key syntax (e.g. 'Control+A').

ParametersJSON Schema

Name	Required	Description	Default
`key`	Yes	Key to press, e.g. 'Enter', 'Tab', 'Escape', 'Control+A'
`selector`	No	Element to focus + press against; omit to press the focused element

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate the tool is not read-only and not destructive. The description adds behavior details: key can be sent to a specific element via selector or to the focused element, and supports Playwright key syntax for combinations like 'Control+A'.

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?

Two sentences only, each serving a purpose. The first sentence states the action and gives examples, the second explains the selector behavior. No wasted words.

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?

For a simple 2-parameter tool with annotations and no output schema, the description covers the core behavior and key syntax. It doesn't mention error handling or return values, but those are not critical for this tool.

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?

Schema coverage is 100%, but the description adds value by providing examples (e.g., 'Enter', 'Tab', 'Escape', 'Control+A') and explaining the conditional behavior of the selector parameter. This goes beyond the schema's bare parameter descriptions.

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: pressing a keyboard key like 'Enter', 'Tab', or 'Escape'. It provides specific examples and distinguishes from sibling tools like 'type' (for text) and 'click' (for mouse actions).

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 explains when to use the tool (submit a form, navigate with Tab, etc.) and how to target elements via selector or focused element. It does not explicitly state when not to use it, but the context and sibling names provide sufficient guidance.

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

resizeResize viewportA

Resize the viewport, e.g. to check a responsive breakpoint before screenshotting.

ParametersJSON Schema

Name	Required	Description	Default
`width`	Yes	Viewport width in px
`height`	Yes	Viewport height in px

TDQS

A4.1/5.0

Behavior3/5

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

Annotations set destructiveHint=false and readOnlyHint=false, and the description simply states the action (resize) without adding deeper behavioral context. While it doesn't contradict, it also doesn't elaborate on potential side effects like impact on other tools or state persistence. With annotations carrying the safety profile, a score of 3 is appropriate.

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 sentence that efficiently conveys the purpose and a typical use case. Every word is meaningful and there is no excess text.

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 the tool's simplicity (2 parameters, no output schema, no nested objects) and full schema coverage, the description is complete enough. It clearly explains what the tool does and offers a contextual example for when it is useful.

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?

The input schema covers both parameters (width, height) with 100% description coverage, including units (px). The description adds no additional parameter details beyond the schema. As schema coverage is high, baseline score of 3 applies.

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 resizes the viewport, using a specific verb and resource. It also provides a concrete use case ('check a responsive breakpoint before screenshotting'), which distinguishes it from sibling tools like 'screenshot'.

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 gives a clear example of when to use the tool ('before screenshotting'), which implies context. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a perfect score.

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

screenshotScreenshotA

Read-only

Screenshot the current page and return it as a viewable image — see the actual rendered UI instead of guessing from code. Prefer selector (one element, cheapest) over the default viewport, and viewport over fullPage (priciest); use the smallest capture that answers the question. Requires navigate first.

ParametersJSON Schema

Name	Required	Description
`format`	No	png (default, lossless) or jpeg (smaller payload; fine for whole-page layout checks, not pixel-level detail)
`quality`	No	JPEG quality 1-100 (default 80); ignored for png
`fullPage`	No	Capture the full scrollable page, not just the viewport (more expensive — use only when the full layout matters)
`selector`	No	CSS selector or Playwright locator (e.g. 'text=Submit') to capture one element only

TDQS

A4.7/5.0

Behavior5/5

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

Annotations indicate readOnlyHint=true, destructiveHint=false. The description adds that a navigation is required first and gives cost hierarchy (cheapest/priciest), which are behavioral traits not in annotations. No contradictions.

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?

Two sentences with zero waste. Front-loaded purpose and immediate usage guidance.

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?

For a tool with 4 optional parameters and no output schema, the description covers prerequisites, usage preferences, and purpose. The return type (image) is obvious from the tool name.

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 covers 100% of parameters with descriptions. The description does not add new parameter semantics; it only reinforces efficiency advice. Baseline is 3.

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 takes a screenshot of the current page and returns an image. It distinguishes from sibling tools like click and navigate by focusing on visual capture.

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 explicit guidance: 'Prefer selector over viewport, viewport over fullPage; use smallest capture that answers the question.' Also notes 'Requires navigate first.' This tells the agent when to use each parameter and the prerequisite.

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

typeType text (per-keystroke)A

Type into a field one key at a time (Playwright locator.pressSequentially), firing a keydown/keypress/keyup per character — for inputs whose handlers need real keystrokes and don't react to fill. Set clear to empty the field first.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Text to type
`clear`	No	Clear the field before typing (default false)
`delay`	No	Delay in ms between keystrokes (default 20)
`selector`	Yes	CSS selector or Playwright locator of the field

TDQS

A4.2/5.0

Behavior4/5

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

Annotations indicate the tool is not read-only (readOnlyHint=false) and not destructive. The description adds important behavioral detail: firing keydown/keypress/keyup per character and using pressSequentially. It also clarifies the 'clear' parameter behavior. No contradiction with annotations.

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?

Two sentences: first defines purpose and mechanism, second explains the 'clear' parameter. No superfluous words. Information is front-loaded and efficient.

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 no output schema, the description adequately covers behavior and key parameter. It mentions the delay parameter implicitly via the mechanism. Could mention focus behavior or error handling, but for a simple action tool, it is sufficiently complete.

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 coverage is 100% with descriptions for all 4 parameters. The description adds a brief note about 'clear' emptying the field, which overlaps with the schema description. Baseline 3 is appropriate as it adds marginal value beyond the schema.

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 types text per-keystroke using Playwright's pressSequentially, and explicitly distinguishes itself from the sibling 'fill' tool by specifying the use case for inputs requiring real keystrokes. Verb 'Type' with resource 'field' and mechanism is specific.

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 explicit context for when to use: for inputs with handlers needing real keystrokes that don't react to fill. It implies fill as an alternative but does not explicitly list when not to use or exclude other siblings like 'press' or 'click'.

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. Dates show when Glama detected each change.

3 tool updatesv1.1.0Jul 11, 2026
- Addedfill
- Addedpress
- Addedtype
5 tool updatesv1.0.0Jul 8, 2026
- First observedclick
- First observedconsole_logs
- First observednavigate
- First observedresize
- First observedscreenshot

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: clicking, filling inputs, navigating, taking screenshots, etc. There is no functional overlap or ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent lowercase_snake_case verb pattern (click, fill, navigate, press, resize, screenshot, type), except console_logs which is a noun but still clear. Overall very consistent.

Tool Count5/5

With 8 tools, the server is well-scoped for browser automation and visual inspection. Each tool serves a necessary function without excessive granularity.

Completeness4/5

The tool set covers core browser interactions (navigation, clicking, input, keyboard, screenshots) and console logs. Minor gaps like explicit wait or scrolling are absent, but the surface is sufficient for most visual inspection tasks.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

sncro A
io.github.scottconfusedgorilla
Live browser debugging for AI assistants — DOM, console, network via MCP.
Browser Automation Developer Tools Monitoring
2
ShotAPI MCP Server A
io.github.smallhandsome
Screenshot and HTML render MCP server for AI agents
Browser Automation Image & Video Processing
21
mintqa-mcp
io.github.adamgusky
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Testing & QA Tools CI/CD & DevOps
2
render-mcp A
io.github.RodRomer
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
61

Related MCP Servers

PuppeteerMCP Server
Browser Automation Web Scraping Monitoring
hushaudio
A
license
B
quality
D
maintenance
An MCP server that enables AI assistants to capture and analyze web page screenshots using Puppeteer, supporting multi-breakpoint captures, error reporting, and page interactions.
Updated a year ago (2025-06-08 04:11 UTC)
1
48
6
MIT
Browser MCP
Browser Automation Web Scraping
blink-new
A
license
Not graded
quality
D
maintenance
An MCP server for browser automation using Puppeteer that enables AI assistants to navigate web pages, interact with UI elements, and capture screenshots. It supports comprehensive web tasks including form filling, content extraction, and executing custom JavaScript within the browser context.
Updated 7 months ago (2026-01-29 00:41 UTC)
1
MIT
mcp-page-capture
Browser Automation Web Scraping
chasesaurabh
A
license
A
quality
D
maintenance
An MCP server that uses headless Chromium (Puppeteer) to capture pixel-perfect screenshots and extract DOM from URLs, with LLM-friendly step-based workflows.
Updated 8 months ago (2025-12-24 04:52 UTC)
2
22
3
MIT
puppeteer
Browser Automation Web Scraping
silvino-av
F
license
Not graded
quality
D
maintenance
MCP server for headless browser automation using Puppeteer, enabling AI to navigate, click, fill forms, take screenshots, and execute JavaScript on web pages.
Updated 10 months ago (2025-10-23 23:42 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MatinMHF/visual-inspector-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

visual-inspector-mcp

Why

Tools

Requirements

Installation

Configuration

Claude Code

Claude Desktop (or any client using claude_desktop_config.json)

Other MCP clients

Usage

Design notes

Security note

Development

Changelog

v1.1.0

v1.0.0

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Claude Desktop (or any client using `claude_desktop_config.json`)