Skip to main content
Glama

open-vision-mcp

Provider-neutral Vision MCP Server — image analysis via 10 inference providers through a single MCP server.

License: MIT TypeScript Node.js

⚠️ Validation status: This server is engineering-validated (163/163 unit/integration tests pass) but live provider validation is pending. No provider has been tested end-to-end with real API credentials yet. Cerebras vision support is specifically unverified. See the Validation Status section below.


What It Does

A Model Context Protocol (MCP) server that gives AI agents the ability to see and understand images using any of 9 supported inference providers. All providers are accessed through a single code path with per-provider configuration.

Perfect for screenshots, photos, diagrams, webpage analysis, and mobile app UI review.


Related MCP server: universal-image-mcp

Supported Providers

Provider

PROVIDER

Default baseUrl

Suggested vision model

MODEL required?

Notes

OpenRouter

openrouter

https://openrouter.ai/api/v1

google/gemini-2.0-flash-exp:free

No (default: anthropic/claude-3.5-sonnet)

Sends HTTP-Referer/X-Title ranking headers

OpenAI

openai

https://api.openai.com/v1

gpt-4o

No

Together

together

https://api.together.xyz/v1

(check Together's model catalog)

Yes

Multi-model aggregator

DeepInfra

deepinfra

https://api.deepinfra.com/v1/openai

(check DeepInfra's catalog)

Yes

Multi-model aggregator

Fireworks

fireworks

https://api.fireworks.ai/inference/v1

(check Fireworks' catalog)

Yes

Multi-model aggregator

Groq

groq

https://api.groq.com/openai/v1

llama-3.2-90b-vision-preview

No

Fast inference

Chutes

chutes

https://llm.chutes.ai/v1

(check Chutes' /models for supported_features)

Yes

Per-model capability preflight

Cerebras

cerebras

https://api.cerebras.ai/v1

llama-4-scout-17b-16e-instruct

No

⚠️ Vision support unverified

Azure OpenAI

azure

(user-supplied deployment URL)

(deployment-configured)

No (ignored)

Requires BASE_URL with ?api-version=; uses api-key header

Ollama

ollama

http://localhost:11434

llama3.2-vision

No

Local (default) or Cloud (BASE_URL=https://api.ollama.com); uses native /api/chat endpoint


Quick Start

Prerequisites

  • Node.js 18+

  • An API key for at least one provider above

# Set your provider, API key, and model
export PROVIDER=openrouter
export API_KEY=sk-or-v1-your-api-key-here
export MODEL=google/gemini-2.0-flash-exp:free

# Run the server
npx open-vision-mcp

Option 2: Install globally

npm install -g open-vision-mcp
open-vision-mcp

Option 3: Clone and build

git clone https://github.com/abyssbugg/open-vision-mcp.git
cd open-vision-mcp
npm install
npm run build
node dist/index.js

Configuration

All configuration is via environment variables.

Environment Variables

Variable

Required?

Default

Purpose

PROVIDER

No

openrouter

Provider discriminator (one of the 9 above)

API_KEY

Yes

API key for the selected provider

MODEL

Depends

Per-provider default

Model id (required for together, deepinfra, fireworks, chutes; ignored by azure)

BASE_URL

No (yes for azure)

Per-provider default

Full-prefix base URL (must include /v1 or /api/v1 as appropriate). Azure requires the full deployment URL with ?api-version=.

EXTRA_HEADERS

No

Per-provider default

JSON object string of extra HTTP headers (e.g., OpenRouter's HTTP-Referer/X-Title)

LOG_LEVEL

No

info

Log level: debug, info, warn, error

MAX_IMAGE_SIZE

No

10485760 (10MB)

Maximum image size in bytes

RETRY_ATTEMPTS

No

3

(Reserved — not yet implemented)

PORT

No

3000

(Reserved — not used by stdio transport)

Legacy Environment Variables (backwards compatible)

If the new variables above are unset, the server falls back to the legacy OpenRouter variables:

Legacy variable

Maps to

OPENROUTER_API_KEY

API_KEY

OPENROUTER_MODEL

MODEL

OPENROUTER_BASE_URL

BASE_URL

Resolution precedence: new variable > legacy variable > per-provider default.

Existing OpenRouter users with only OPENROUTER_API_KEY set continue to work with zero config changes. The server defaults to PROVIDER=openrouter and lifts the legacy variables into the new fields.

Azure OpenAI Configuration

Azure is the only provider that requires BASE_URL (no per-provider default). The BASE_URL must be the full deployment URL including the api-version query parameter:

export PROVIDER=azure
export API_KEY=your-azure-resource-key
export BASE_URL=https://your-resource.openai.azure.com/openai/deployments/your-deployment?api-version=2024-02-15-preview

For Azure, MODEL is ignored — the deployment name is in BASE_URL. Azure uses the api-key header (not Authorization: Bearer). Azure has no /models endpoint; testConnection and validateModel return true without making HTTP calls (the first analyze_image call is the real health check).


MCP Client Configuration

Claude Code

Add to ~/.claude.json:

{
  "mcp": {
    "servers": {
      "vision": {
        "command": "npx",
        "args": ["open-vision-mcp"],
        "env": {
          "PROVIDER": "openrouter",
          "API_KEY": "sk-or-v1-your-key-here",
          "MODEL": "google/gemini-2.0-flash-exp:free"
        }
      }
    }
  }
}

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "vision": {
      "command": "npx",
      "args": ["open-vision-mcp"],
      "env": {
        "PROVIDER": "openai",
        "API_KEY": "sk-your-key-here",
        "MODEL": "gpt-4o"
      }
    }
  }
}

Other MCP Clients

  • Cursor: ~/.cursor/mcp.json

  • Cline: ~/.cline/mcp.json

  • Windsurf: MCP settings file

  • Check your agent's MCP documentation

Switching Providers

Change only the env vars — no code changes:

# Switch from OpenRouter to Groq
export PROVIDER=groq
export API_KEY=gsk-your-groq-key
export MODEL=llama-3.2-90b-vision-preview

npx open-vision-mcp

Tools

The server exposes 3 MCP tools. Tool names and schemas are identical for all providers.

analyze_image

General image analysis. Supports base64, file paths, and URLs.

Parameters:

  • typebase64 | file | url

  • data — image data (base64 string, file path, or URL)

  • mimeType — MIME type (required for base64)

  • prompt — custom analysis prompt (optional)

  • formattext | json (default: text)

  • maxTokens — max response tokens (default: 4000)

  • temperature — sampling temperature 0–2 (default: 0.1)

analyze_webpage_screenshot

Webpage screenshot specialist. Extracts content, layout, navigation, forms, and accessibility info.

Additional parameters:

  • focusArealayout | content | navigation | forms | interactive | accessibility

  • includeAccessibility — include accessibility analysis (default: true)

  • formattext | json (default: json)

analyze_mobile_app_screenshot

Mobile app screenshot specialist. UI design, UX, platform conventions, accessibility.

Additional parameters:

  • platformios | android | auto-detect (default: auto-detect)

  • focusAreaui-design | user-experience | navigation | accessibility | performance | onboarding

  • includeUXHeuristics — include Nielsen's 10 heuristics (default: true)

  • formattext | json (default: json)


Validation Status

Engineering Validation: COMPLETE

  • 163/163 unit + integration tests pass (JSON reporter; npm test)

  • npm run build exit 0 — TypeScript strict mode, zero errors

  • npm run lint exit 0 — ESLint, zero errors

  • Sentinel 8/8 — black-box MCP protocol test over stdio

  • Phase 2B.5 Stage 1: 10/10 mandatory gates passed — keyless validation (configuration, request construction, auth headers, error handling, image processing, timeouts, capabilities, base URLs, logging)

  • MCP contract byte-identical to baseline — tool names, schemas, and output format unchanged from the original upstream

  • Backwards compatibility verified — legacy OPENROUTER_API_KEY env var fallback works end-to-end

Operational Validation: PENDING

  • Live provider validation (Stage 2): paused pending valid API credentials. No provider has been tested end-to-end through analyze_image with a real key. Stage 2 may be executed at any future time when credentials become available.

  • Cerebras vision support: UNVERIFIED. The llama-4-scout-17b-16e-instruct model is configured as the default, but whether it accepts multimodal (image) input has not been confirmed. If it doesn't support vision, the user gets a clear provider-aware error at runtime.

  • Provider response shapes: unit tests mock axios and assert the request/response shape. Live APIs have not been confirmed to match the mocked shapes, though all providers are OpenAI-compatible per their official documentation.

What This Means for Users

The server is architecturally sound and thoroughly unit-tested. The provider abstraction, configuration resolution, request construction, error handling, and MCP protocol are all verified. However, no live API call has been made against any provider. Users should be aware that:

  1. The request body shape is correct per provider documentation (verified in Phase 2A research), but not confirmed against a live 200 response.

  2. Cerebras may not support vision input — use a different provider if vision is critical.

  3. If a provider's API has changed since the Phase 2A research (conducted June 2026), the server may need a config update.


Supported Image Formats

Format

Extension

MIME Type

Status

JPEG

.jpg, .jpeg

image/jpeg

PNG

.png

image/png

WebP

.webp

image/webp

GIF

.gif

image/gif

Max size

10MB (configurable via MAX_IMAGE_SIZE)

MIME type detection is signature-based (no native dependencies).


Development

# Install dependencies
npm install

# Build
npm run build

# Run in development mode
npm run dev

# Run tests
npm test                          # all tests (JSON reporter for counts)
npx vitest run test/unit          # unit tests only
npx vitest run test/integration   # integration tests only

# Lint and format
npm run lint
npm run format

# Clean
npm run clean

Troubleshooting

"API_KEY environment variable is required"

Set API_KEY (or the legacy OPENROUTER_API_KEY) to your provider's API key.

"MODEL environment variable is required for provider 'together'"

The together, deepinfra, fireworks, and chutes providers are multi-model aggregators with no default model. Set MODEL to a vision-capable model id from the provider's catalog.

"Unknown PROVIDER 'xyz'"

The PROVIDER value must be one of: openrouter, openai, together, deepinfra, fireworks, groq, chutes, cerebras, azure.

"BASE_URL is required for provider 'azure'"

Azure requires BASE_URL to be the full deployment URL including ?api-version=. There is no per-provider default.

" API Error: ..."

The error message includes the provider id (e.g., openai API Error: Invalid API key). This confirms the provider-aware error handling is working. Check your API key and model id.

Ollama: connection refused (local)

Ensure Ollama is running locally (ollama serve or ollama pull <model>). The default BASE_URL is http://localhost:11434. For Ollama Cloud, set BASE_URL=https://api.ollama.com and API_KEY=<cloud-token>.


Attribution

This project is a fork of JonathanJude/openrouter-image-mcp (MIT license), refactored to be provider-neutral with support for 10 inference providers.


License

MIT — see LICENSE.

Available Tools

3 tools
analyze_imageB

Analyze images using the configured vision provider. Supports various input formats including base64, file paths, and URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesThe image data (base64 string, file path, or URL)
typeYesThe type of image input
formatNoOutput format (default: text)
promptNoCustom prompt for image analysis (optional)
mimeTypeNoMIME type of the image (required for base64 input)
maxTokensNoMaximum tokens in response (default: 4000)
temperatureNoSampling temperature (default: 0.1)

TDQS

B3.1/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 full burden. It does not disclose behavioral traits such as read-only nature, permissions, rate limits, or side effects. The description is too minimal.

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 concisely conveys the core purpose. It front-loads the action and resource, and is easily readable.

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 7 parameters and no output schema, the description covers the basic purpose but does not describe return values, error behavior, or how the analysis is performed. Somewhat incomplete for a tool of this complexity.

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 baseline is 3. The description mentions supported input formats but adds no additional meaning beyond the schema descriptions. No extra value.

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 analyzes images using a vision provider, and lists supported input formats. However, it does not differentiate from sibling tools like analyze_mobile_app_screenshot or analyze_webpage_screenshot, which are more specific.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this generic image analysis tool versus the screenshot-specific alternatives. The description lacks context for selection.

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

analyze_mobile_app_screenshotA

Specialized tool for analyzing mobile app screenshots. Provides insights into UI design, user experience, platform conventions, and app functionality.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesThe mobile app screenshot data (base64 string, file path, or URL)
typeYesThe type of image input
formatNoOutput format (default: json for structured mobile analysis)
mimeTypeNoMIME type of the image (required for base64 input)
platformNoMobile platform (default: auto-detect)
focusAreaNoSpecific area to focus on (optional)
maxTokensNoMaximum tokens in response (default: 4000)
includeUXHeuristicsNoInclude UX heuristic evaluation (default: true)

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must bear the burden of behavioral disclosure. It states the tool provides insights but does not disclose any behavioral traits such as whether it modifies anything, required permissions, rate limits, or that it is a read-only analysis. This is insufficient for an agent to understand side effects.

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?

The description is two sentences long and front-loaded with the purpose. It is concise with no redundant words. However, it could be slightly more structured by listing the focus areas explicitly.

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 has 8 parameters and no output schema or annotations, the description is incomplete. It does not explain the return format (default json), behavior of the platform auto-detect, or how focus areas affect the analysis. An agent would need more context to use it confidently.

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?

All 8 parameters have descriptions in the schema (100% coverage), so the description does not need to add much. It mentions 'insights into UI design, user experience, etc.' which aligns with the platform and focusArea parameters but does not add significant new meaning 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 is a specialized tool for analyzing mobile app screenshots, providing insights into UI design, UX, platform conventions, and functionality. This distinguishes it from sibling tools analyze_image and analyze_webpage_screenshot, which are for general images and webpages respectively.

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 mobile app screenshots via 'specialized' and the listed insights, and the sibling tools provide context for when not to use (generic images, webpages). However, it does not explicitly state when to avoid this tool or provide alternatives.

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

analyze_webpage_screenshotB

Specialized tool for analyzing webpage screenshots. Extracts content, layout information, and interactive elements from web pages.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesThe webpage screenshot data (base64 string, file path, or URL)
typeYesThe type of image input
formatNoOutput format (default: json for structured webpage analysis)
mimeTypeNoMIME type of the image (required for base64 input)
focusAreaNoSpecific area to focus on (optional)
maxTokensNoMaximum tokens in response (default: 4000)
includeAccessibilityNoInclude accessibility analysis (default: true)

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 the full burden of disclosing behavioral traits. It only states what the tool extracts but omits details about processing, privacy, size limits, or output structure beyond what the schema implies.

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 highly concise with two sentences, front-loading the core purpose. No unnecessary words.

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 7 parameters and no output schema or annotations, the description lacks important behavioral context such as input constraints, output format details, or handling of optional parameters. It is insufficient for an agent to reliably use the 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?

The schema covers 100% of parameters with descriptions, so the description adds limited value beyond stating the extraction focus. Baseline 3 is appropriate as the schema does the heavy lifting.

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 is for analyzing webpage screenshots and extracting content, layout, and interactive elements. However, it does not explicitly differentiate from sibling tools like analyze_image or analyze_mobile_app_screenshot, leaving the agent to infer the scope.

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 that this tool is specialized for webpages, suggesting it should be used over the general analyze_image for that context. However, it provides no explicit when-to-use or when-not-to-use guidance, nor does it name alternatives.

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.

  1. 3 tool updatesv2.1.0
    • First observedanalyze_image
    • First observedanalyze_mobile_app_screenshot
    • First observedanalyze_webpage_screenshot

TDQS

B3.4/5.0
Disambiguation4/5

Tools are mostly distinct: analyze_image is generic, while analyze_mobile_app_screenshot and analyze_webpage_screenshot target specific domains. However, an agent could potentially use analyze_image for screenshots, causing some overlap.

Naming Consistency5/5

All tool names follow a consistent 'analyze_<noun>' pattern, making them predictable and easy to understand.

Tool Count4/5

Three tools is a reasonable number for a focused vision analysis server. It is slightly on the lower end but not overly sparse, covering both general and specialized analysis.

Completeness3/5

The tool set covers basic image analysis and two common screenshot types. Missing operations like object detection or text extraction for general images are notable gaps, but the core analysis use case is addressed.

Maintenance

ActivityStale
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/abyssbugg/open-vision-mcp'

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