Skip to main content
Glama
JaviGala

web-perception-mcp

by JaviGala
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

web-perception MCP Server

Test

A small local Model Context Protocol (MCP) server that gives non-visual models access to visual analysis of local images and rendered webpages through a configurable vision-capable model.

non-visual model → local image or rendered webpage → vision model → grounded text/JSON result

The server is intentionally narrow: it exposes three tools for analysing existing images, capturing webpages, and analysing webpage screenshots. It is an experimental project rather than production-audited infrastructure.

NOTE

As of v0.3.0, active feature development is paused. The project is in maintenance mode: future changes should focus on clear bugs, security fixes, and necessary compatibility updates rather than expanding scope.

When it is useful

Use this MCP when a model needs information that depends on visual appearance rather than text or HTML alone, for example:

  • analysing a screenshot, mockup, diagram, chart, or photograph;

  • inspecting webpage layout, visual hierarchy, canvas content, charts, or rendered state;

  • saving rendered webpage screenshots for later inspection.

Do not use it for ordinary web search, primarily textual webpage retrieval, general scraping, or full browser automation. It does not click through flows, fill forms, expose the full DOM, or bypass Cloudflare, captchas, paywalls, login requirements, regional blocks, or other access controls.

Related MCP server: custom-browser-mcp

What it installs and what leaves your machine

IMPORTANT

The two webpage tools require Chromium Headless Shell managed by Playwright. The browser download is distinct fromnpm install. Using --only-shell avoids downloading the separate full Chromium build; the exact size varies by Playwright version and operating system.

  • analyze_image reads local images and does not launch Chromium.

  • capture_page_screenshot and analyze_page_screenshot launch Chromium locally to render webpages.

  • The server does not include a vision model. Analysis requests are sent to the configured external vision provider.

  • Local images, webpage screenshots, prompts, and optional compact page context may leave your machine when an analysis tool is used.

  • capture_page_screenshot does not contact the vision provider.

Review the provider's privacy, retention, and data-processing policies before analysing sensitive material.

Tools

Tool

Use when

Result

Vision provider call?

analyze_image

An existing local image, screenshot, mockup, diagram, chart, or photograph needs visual analysis.

Visual analysis of one or more local files.

Yes

capture_page_screenshot

The rendered screenshot files are needed without visual interpretation.

Local screenshot paths, metadata, and optional compact page context.

No

analyze_page_screenshot

The answer depends on a webpage's rendered appearance, layout, hierarchy, canvas, charts, or visual state.

Visual analysis plus capture metadata and optional compact page context.

Yes

The server also supplies concise MCP instructions and tool descriptions so compatible clients can help models distinguish these cases. Some clients prefix tool names with the configured server identifier; models should use the exact tool names exposed by the client rather than reconstructing them.

Choosing a screenshot mode

  • viewport is the default. Use it for short pages, the initial visible state, or when the task does not require content below the first viewport.

  • sections captures ordered viewport-sized images across a long page. It starts at start_y: 0 by default. When a pass is truncated, use its next_start_y as the start_y of a later call to continue sequentially. Continuation is stateless: every call reloads the URL, so check first_captured_y and warnings rather than assuming pixel-perfect continuity.

  • full_page creates one complete-page image. Reserve it for specifically requested, reasonably short pages; very tall images can reduce visual legibility.

  • element captures one CSS selector when the task concerns a specific visible component.

Operational effects and MCP risk hints

The tools publish the standard MCP readOnlyHint, destructiveHint, idempotentHint, and openWorldHint annotations. These are behavioural hints for clients and models, not security guarantees.

Tool

Read only?

Destructive?

Idempotent?

Open world?

Main operational effects

analyze_image

Yes

No

No

Yes

Reads local images and sends images and prompts to the configured provider; repeated calls may consume quota and produce different responses.

capture_page_screenshot

No

No

No

Yes

Makes a network request, launches Chromium, and creates new local screenshot files without calling the vision provider.

analyze_page_screenshot

No

No

No

Yes

Makes a network request, launches Chromium, creates local screenshots, and sends screenshots, prompts, and optional page context to the configured provider.

Here, “read only” means that the tool does not modify its environment. It does not mean that a call has no privacy, cost, network, CPU, memory, or disk effects. The two screenshot tools are marked non-read-only because they create local files; they are non-destructive because they do not intentionally overwrite or delete existing data. All three are non-idempotent because retries can create additional files, consume provider quota, or produce different model output.

Requirements

  • Node.js 20+

  • An MCP client that can run local stdio servers

  • An API key for a vision provider with an OpenAI-style /chat/completions endpoint when using either analysis tool

  • Playwright Chromium Headless Shell for webpage capture or analysis

Install

git clone https://github.com/JaviGala/web-perception-mcp.git
cd web-perception-mcp
npm install
npx playwright install --only-shell chromium
cp .env.example .env

The Playwright command downloads the headless browser runtime without the separate full Chromium build. Users who only intend to inspect local images still need the JavaScript dependencies, but analyze_image does not launch the browser.

Set at least these values in .env:

VISION_API_KEY=your_key_here
VISION_BASE_URL=https://your-provider.example/v1
VISION_MODEL=your-vision-model

The provider must accept an OpenAI-style /chat/completions request with mixed text and image_url content. Compatibility varies between providers and models.

MCP client configuration

A common local stdio configuration shape is:

{
  "mcpServers": {
    "web-perception": {
      "command": "node",
      "args": ["/absolute/path/to/web-perception-mcp/src/server.js"]
    }
  }
}

MCP client schemas vary and may use a different top-level key or command format. Keep provider credentials in the repository's ignored .env file unless the client specifically requires environment variables. Avoid defining the same values in both places: non-empty variables inherited by the MCP process take precedence over matching .env values.

Use forward slashes or escaped backslashes in Windows JSON paths. For a tested Cline configuration, see docs/cline-setup.md.

Connection check

After reconnecting the MCP server, ask the client to list the available tools or make one explicit low-risk request, such as saving a screenshot of a public webpage. If the client reports an invalid prefixed tool name, reconnect the server and start a fresh conversation before changing the server or tool names.

Maintainers can use the small model discovery check to compare tool selection before and after metadata changes without requiring real provider calls for every case.

Main configuration

Variable

Default

Purpose

VISION_API_KEY

required

Vision-provider API key.

VISION_BASE_URL

provider fallback

Base URL; the server appends /chat/completions.

VISION_MODEL

provider fallback

Vision-capable model.

VISION_PROVIDER_NAME

vision provider

Label used in logs and errors.

VISION_TEMPERATURE

0.3

Default model temperature.

VISION_MAX_TOKENS

2000

Default response limit; a tool argument can override it.

VISION_TIMEOUT_MS

60000

Timeout for the provider request and response body.

MAX_IMAGES_PER_REQUEST

8

Maximum images sent in one vision request.

MAX_IMAGE_BYTES

10485760

Maximum size of each local image.

ALLOWED_IMAGE_DIRS

project and temporary directories

Comma-separated allowlist for local image paths.

SCREENSHOT_OUTPUT_DIR

OS temporary directory

Where webpage screenshots are written.

SCREENSHOT_AUTO_CLEANUP

true

Remove old MCP-created screenshots during later captures.

SCREENSHOT_RETENTION_MINUTES

1440

Screenshot retention window.

ALLOWED_DOMAINS

empty

Optional comma-separated public-domain allowlist.

BLOCKED_DOMAINS

empty

Optional comma-separated domain denylist.

ALLOW_LOCALHOST

false

Local-development escape hatch for loopback URLs.

See .env.example for the complete configuration template. New setups should use the VISION_* names; older provider-specific aliases are retained only for compatibility.

Structured output

The two analysis tools accept response_format: "text" (the default) or response_format: "json_object".

When JSON is requested, the MCP asks the provider for a single findings object with this structure:

{
  "summary": "Concise answer to the user's question.",
  "observations": ["Directly visible facts."],
  "interpretations": ["Inferences or recommendations based on those facts."],
  "uncertainty": ["Anything that cannot be determined confidently."]
}

All four fields are required by the output contract; the arrays may be empty. This findings object is not the top-level MCP response. Successful tool calls are returned inside the server's standard envelope:

{
  "ok": true,
  "data": {
    "analysis": "raw provider response",
    "parsed": {
      "summary": "...",
      "observations": [],
      "interpretations": [],
      "uncertainty": []
    }
  },
  "warnings": [],
  "meta": {}
}

The raw provider response is returned in data.analysis; data.parsed contains the parsed findings when json_object is requested. Other tool-specific fields are also present inside data.

json_object is a request to the configured provider, not a guarantee that the provider will obey the contract. The parser currently checks JSON syntax, not the four-field schema. A provider can therefore return syntactically valid JSON with missing, additional, or incorrectly typed fields without triggering fallback. Callers that depend on the exact structure should validate data.parsed themselves and check warnings.

Some providers or models may ignore JSON mode. If a non-empty response is not valid JSON, the MCP preserves the raw response in data.parsed.summary, returns empty observations and interpretations arrays, adds an uncertainty entry explaining the parse failure, and reports this warning:

Vision response was not valid JSON; returned raw summary fallback.

An empty provider response returns data.parsed: null and the warning Empty response. Direct JSON and JSON wrapped in Markdown code fences are both accepted. Structured-output reliability still depends on the configured provider and model.

Screenshots and diagnostics

Screenshots are stored by default in an app-owned folder inside the operating-system temporary directory. The tools return local paths and file:// URLs but do not open or execute them.

Section capture uses several viewport-sized screenshots rather than one extremely tall image. analyze_page_screenshot sends at most eight sections to the vision model; capture-only requests can create up to twenty.

Because sections stops at max_sections, it may not reach the page end. Check reached_end and truncated; start_y, first_captured_y, document_height, last_captured_bottom, remaining_pixels, next_start_y, max_sections, and max_sections_reached describe the captured range. A truncated pass returns a warning and normally a numeric next_start_y; a pass that reaches the current page end returns next_start_y: null.

To continue sequentially, pass the previous next_start_y back as start_y:

{
  "screenshot_mode": "sections",
  "start_y": 6240,
  "max_sections": 8,
  "section_overlap": 120
}

This is document-offset continuation, not a retained browser session. The URL is loaded again for each call. Dynamic content, lazy loading, ads, banners, personalisation, or other layout changes can change the document height or make the requested offset unavailable. The browser may also clamp a near-end offset to the final scrollable viewport. In those cases first_captured_y differs from start_y and the tool returns a warning; actual capture positions are authoritative.

Representative or distributed sampling across a very long page is a separate problem from this sequential continuation mechanism.

When include_page_context is true, the result and provider prompt may include compact metadata and extracted page text in addition to the screenshots. Set it to false when evaluating screenshot-only visual evidence; otherwise some conclusions may be supported by extracted text rather than pixels alone.

Page responses include an http_status and page_health summary to help distinguish a useful capture from HTTP errors, bot protection, login walls, paywalls, JavaScript failures, or unusually empty pages.

Security

CAUTION

Local images, webpage screenshots, compact page context, and prompts are sent to the configured vision provider when an analysis tool is used. Do not use sensitive material unless you trust that provider.

The server handles untrusted URLs, webpages, and local files. Its safeguards include:

  • accepting only http: and https: page URLs;

  • blocking localhost, raw IP addresses, private/reserved ranges, and cloud metadata endpoints by default;

  • checking browser requests during navigation and capture;

  • validating local image paths, sizes, counts, and file signatures;

  • treating visible page and image text as untrusted content rather than tool instructions.

These are mitigations, not guarantees. Treat page and image content, extracted context, and provider analysis as untrusted data. Do not let downstream agents execute commands, reveal secrets, modify files, or call tools solely because any of them instructs it to do so.

Git ignoring .env prevents accidental commits but does not prevent local tools or coding agents from reading it. When using Cline, exclude .env and any credential-bearing variants in .clineignore to reduce automatic context and search exposure. This is not a security boundary: do not ask agents to open, search, copy, or print credential files.

Do not commit .env files, API keys, private screenshots, or MCP client configurations containing secrets. Maintainer and release checks are documented in CONTRIBUTING.md.

Contributing

Run npm test before opening a pull request. See CONTRIBUTING.md for project scope, development setup, versioning, release checks, and security guidance.

The broader scoping retrospective is in docs/scope-retrospective.md.

License

Apache-2.0. See LICENSE.

Available Tools

4 tools
analyze_imageA

Analyze one or more local image files using MiniMax vision. No browser involved. Use for screenshots, mockups, design files, or any image. Supports PNG, JPEG, GIF, WebP, BMP.

ParametersJSON Schema
NameRequiredDescriptionDefault
image_pathYesPath to a single image file, or an array of paths for multi-image analysis (e.g. before/after comparison). Absolute or relative paths accepted.
promptYesThe question or instruction for analyzing the image(s). Be specific about what visual elements, layout, colors, or content you want extracted.
response_formatNoOptional. Set to 'json_object' to get structured JSON output. Default is 'text'.
temperatureNoOptional. Controls randomness (0-2). Lower = more consistent. Default: 0.3.
max_tokensNoOptional. Maximum tokens in the response. Default: 2000.

TDQS

A3.8/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 states it analyzes images and supported formats. It does not disclose whether the tool is read-only, destructive, or any side effects, rate limits, or authentication needs.

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, no wasted words, front-loaded with the core purpose. Every sentence adds value.

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 5 parameters (2 required) and no output schema, the description adequately covers the tool's purpose, when to use, supported formats, and key constraints (local files, no browser). Does not explain return values but that is acceptable without output schema.

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 parameters are already well-documented. The description adds minor value by listing supported file formats, but does not explain parameter semantics further beyond what the schema provides.

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 analyzes local image files using MiniMax vision, specifies no browser involvement, and lists use cases (screenshots, mockups, etc.), distinguishing it from sibling page-related 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 explicitly says to use for screenshots/mockups/any image and notes 'No browser involved', implying when to use vs page-analysis siblings, but does not explicitly state when not to use or list alternative tools.

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

analyze_page_visualA

Analyze a webpage visually using screenshot + DOM structure + MiniMax vision. Use for design critique, UX review, visual hierarchy, layout analysis, UI bugs, and above-the-fold analysis. Defaults to viewport screenshot. Returns structured findings with element refs and evidence.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to analyze. Must be http:// or https://.
promptYesWhat to analyze. Be specific: 'critique the visual hierarchy', 'check spacing consistency', 'evaluate the hero section'.
viewportNo
screenshot_modeNoviewport: above-the-fold only. full_page: entire scrollable page. element: specific element by ref. sections: multiple viewport shots.viewport
element_refNoElement ref for element screenshot mode (e.g. 'e12').
wait_untilNonetworkidle
include_a11y_treeNo
response_formatNojson_object
temperatureNo
max_tokensNo
headlessNoRun browser in headless mode. Set to false for debugging.

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It discloses default behavior (viewport screenshot) and output format (structured findings with element refs and evidence). However, it omits details on permissions, cost, latency, or potential side effects, which are moderately important for an AI agent.

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 extremely concise with three focused sentences. It front-loads the core purpose and capabilities, and each sentence contributes valuable information without redundancy.

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 the tool's complexity (11 parameters, no output schema, no annotations), the description is too brief. It does not explain parameter interactions, return structure details, or error handling, which are crucial for the agent to use the tool effectively.

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

Parameters2/5

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

Schema description coverage is low (45%), and the description adds minimal parameter clarification beyond stating the default screenshot mode. Core parameters like prompt, viewport, and wait_until are not elaborated in the description, leaving the agent to rely on the sparse schema 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: analyzing a webpage visually using screenshot, DOM structure, and MiniMax vision. It lists specific use cases (design critique, UX review, visual hierarchy, etc.) and the methodology, which distinguishes it from sibling tools like analyze_image or extract_page_data.

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 explicitly lists use cases such as design critique and UX review, implying when to use this tool. However, it does not explicitly contrast with sibling tools or say when not to use it, leaving some ambiguity.

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

extract_page_dataA

Extract structured data from a webpage matching a provided schema. DOM-first: uses static extraction first, escalates to headless browser then MiniMax vision only if needed. Use for pricing tiers, product info, contact details, speaker lists, tables, API docs, or any structured content.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to extract data from.
schemaYesJSON schema describing the data to extract. Example: {"plans": [{"name": "string", "price": "string", "features": ["string"]}]}
use_vision_if_neededNoIf true, falls back to MiniMax vision when data cannot be extracted from the DOM (e.g. data in images, canvas, charts).
viewportNo
wait_untilNoload

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries full burden. It discloses the extraction strategy (DOM-first, escalating to headless browser then MiniMax vision) and explains the use_vision_if_needed parameter. However, it omits potential side effects like page interaction limits or failure modes.

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: two sentences that are front-loaded with purpose and extraction strategy. Every sentence adds value without redundancy.

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 output schema, 5 parameters with nested objects, the description covers extraction strategy and use cases. However, it lacks details on return format, error handling, or limitations, which are important for complete context.

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

Parameters2/5

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

Schema coverage is 60% (only 3 of 5 parameters have descriptions in the schema). The description adds no information for viewport and wait_until, leaving them undocumented. It does provide a schema example for the 'schema' parameter and clarifies use_vision_if_needed.

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 extracts structured data from a webpage matching a schema, and lists specific use cases like pricing tiers, product info, etc. It distinguishes from sibling tools by focusing on structured extraction vs. image/visual analysis.

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 provides usage scenarios (pricing tiers, etc.) but does not explicitly say when not to use the tool or suggest alternatives. The 'DOM-first' strategy offers some guidance but no direct comparison to siblings.

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

inspect_pageA

Inspect a webpage's structure, metadata, and content. Use for understanding what's on a page without visual analysis. Basic mode uses static fetch (fast, no browser). Full mode uses headless browser for DOM/accessibility/element extraction. Does NOT invoke the vision model.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to inspect. Must be http:// or https://.
detailNobasic: static fetch + readability (fast, no browser). full: headless browser + DOM extraction (slower, more data).basic
viewportNoViewport dimensions for full mode.
wait_untilNoWhen to consider the page loaded (full mode only).load
include_a11y_treeNoInclude compact accessibility tree (full mode only).
include_screenshotNoTake a viewport screenshot and save it (full mode only).
max_text_lengthNoMaximum characters for extracted text.
max_elementsNoMaximum elements in the element map (full mode).
min_bbox_areaNoMinimum bounding box area in px² for elements (full mode).
include_hiddenNoInclude hidden elements in the element map (full mode).

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden. It discloses the two modes (static fetch vs headless browser) and clarifies that no vision model is invoked. However, it does not mention read-only behavior, rate limits, or auth requirements, which are expected but not critical.

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 two sentences: the first states the purpose, the second provides key details. It is front-loaded, concise, and every sentence adds value without redundancy.

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 complexity (10 parameters, no output schema), the description adequately explains the primary distinction between modes and the tool's scope. However, it does not describe the output or what data is returned, which would help an agent understand what to expect.

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 baseline is 3. The description adds context on modes but does not explain other parameters beyond what the schema provides. Since the schema already documents all parameters thoroughly, the description adds limited additional semantics.

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 inspects webpage structure, metadata, and content, and explicitly distinguishes from visual analysis tools. It also notes it does not invoke the vision model, differentiating it from siblings like analyze_image and analyze_page_visual.

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 (understanding a page without visual analysis) and distinguishes two modes (basic vs full) with implications for speed and data depth. However, it does not explicitly state when not to use or list alternative tools beyond the implicit exclusion of visual analysis.

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

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

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct scope: local image analysis, webpage visual analysis, structured data extraction, and page structure inspection. No overlaps or ambiguities.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (analyze_image, analyze_page_visual, extract_page_data, inspect_page), making it easy to predict functionality.

Tool Count5/5

With 4 tools, the set is well-scoped for web perception tasks—neither too sparse nor too bloated, covering the essential operations.

Completeness5/5

Covers all core aspects: image analysis, webpage visual analysis, structured data extraction, and page structure inspection. No obvious gaps for the domain.

Maintenance

ActivitySlowing
ResponsivenessSyncing

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

Latest Blog Posts

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/JaviGala/web-perception-mcp'

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