Skip to main content
Glama

mcp-vision-server

A lightweight MCP server exposing a single tool — describe_image — that forwards a local image file to any OpenAI-compatible vision endpoint and returns the text description.

Most LLMs can't see an image you drop into a chat. This server bridges that gap: the host AI calls describe_image with a file path, your vision model does the actual seeing, and the description flows back into the conversation.

┌──────────┐     MCP (stdio)      ┌─────────────────┐      HTTP POST     ┌──────────────────┐
│  Client  │ ─── describe_image ─▶│  mcp-vision-srv │ ── image+prompt ──▶│  Vision Endpoint │
│  (AI)    │ ◀── text description │   (this repo)   │ ◀──── JSON resp ───│  (vLLM/Ollama/…) │
└──────────┘                      └─────────────────┘                    └──────────────────┘

The server speaks MCP over stdio — it doesn't serve HTTP itself. It reads the file from disk, base64-encodes it, POSTs to your endpoint, and hands the response back as tool output.

Requirements

  • Python ≥ 3.10

  • uv installed

  • A running vision endpoint that speaks the OpenAI chat-completions schema

That last one is not optional. This server has no model of its own — without something listening at VISION_ENDPOINT, every call fails. See Supported Endpoints.

Related MCP server: z_ai_vision_mcp_server_clone

Install

No clone needed — uvx can run it straight from the repo:

uvx --from git+https://github.com/joshsssn/mcp-vision-server mcp-vision-server

Your MCP client will run this for you once configured; the command above is mainly useful to check the server starts.

Claude Code, one line:

claude mcp add vision \
  --env VISION_ENDPOINT=http://localhost:11434/v1/chat/completions \
  --env VISION_MODEL=llama3.2-vision \
  -- uvx --from git+https://github.com/joshsssn/mcp-vision-server mcp-vision-server

VS Code (Copilot Chat) — add to .vscode/mcp.json in your workspace, or to your user settings:

{
  "servers": {
    "mcp-vision-server": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/joshsssn/mcp-vision-server",
        "mcp-vision-server"
      ],
      "env": {
        "VISION_ENDPOINT": "https://api.openai.com/v1/chat/completions",
        "VISION_API_KEY": "sk-your-key-here",
        "VISION_MODEL": "gpt-4o"
      }
    }
  }
}

Claude Desktop — add to claude_desktop_config.json:

{
  "mcpServers": {
    "mcp-vision-server": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/joshsssn/mcp-vision-server",
        "mcp-vision-server"
      ],
      "env": {
        "VISION_ENDPOINT": "https://api.openai.com/v1/chat/completions",
        "VISION_API_KEY": "sk-your-key-here",
        "VISION_MODEL": "gpt-4o"
      }
    }
  }
}

Working from a local clone instead? Replace the git+https://… argument with the path to the repo root.

Local development

git clone https://github.com/joshsssn/mcp-vision-server.git
cd mcp-vision-server
cp .env.example .env    # edit with your endpoint URL, API key, and model name
uvx --from . mcp-vision-server

Configuration

All settings come from environment variables, or a .env file in the project root:

Variable

Default

Description

VISION_ENDPOINT

http://localhost:11434/v1/chat/completions

OpenAI-compatible vision API URL

VISION_API_KEY

ollama

Bearer token for the endpoint

VISION_MODEL

llama3.2-vision

Model name the endpoint expects

VISION_TIMEOUT

60

Request timeout in seconds

VISION_MAX_IMAGE_BYTES

20971520 (20 MB)

Reject images larger than this

The defaults target a local Ollama install, so ollama run llama3.2-vision plus a zero-config client entry is enough to get going.

The env block in your client config overrides .env. Use .env for local dev, the client block for anything you share — no keys end up in the repo either way.

See .env.example for a ready-to-copy template.

Tool: describe_image

Parameter

Type

Required

Default

image

string

yes

prompt

string

no

Describe this image in detail.

image must be an absolute path to a file on disk — not a URL, not a pasted image. Supported formats: PNG, JPG, JPEG, GIF, WEBP.

C:\Users\photos\cat.jpg
/home/user/images/screenshot.png

prompt is any natural-language instruction for the vision model:

  • "Describe this image in detail."

  • "Extract all text from this image."

  • "What colors dominate this image?"

  • "Is there a person in this image? If so, describe them."

Example call:

{
  "tool": "describe_image",
  "arguments": {
    "image": "/home/user/photos/sunset.jpg",
    "prompt": "What colors dominate this image? Is there a person in it?"
  }
}

Supported Endpoints

Anything implementing the OpenAI chat-completions schema with image_url content parts:

Endpoint

Example URL

Notes

Ollama

http://localhost:11434/v1/chat/completions

Easiest local setup

LM Studio

http://localhost:1234/v1/chat/completions

GUI-friendly

vLLM

http://localhost:8000/v1/chat/completions

Great for self-hosted

OpenAI

https://api.openai.com/v1/chat/completions

Cloud, requires API key

Custom / self-hosted

https://your-box/v1/chat/completions

Anything OpenAI-compatible

Troubleshooting

invalid peer certificate: UnknownIssuer on startup. uv uses its own certificate store and doesn't know about TLS-inspecting antivirus software or corporate proxies. Add "UV_NATIVE_TLS": "1" to the env block to make it use the system store instead.

Connection refused / timeout on every call. Nothing is listening at VISION_ENDPOINT. Confirm the endpoint independently before blaming the server:

curl $VISION_ENDPOINT -H "Content-Type: application/json" \
  -d '{"model":"llama3.2-vision","messages":[{"role":"user","content":"hi"}]}'

Tool doesn't appear in the client. Check the MCP logs — in VS Code, the Output panel has a channel per server. A failure to install the package shows up as a non-zero exit before initialize ever completes.

Image rejected for size. Raise VISION_MAX_IMAGE_BYTES, or downscale first. Base64 encoding inflates the payload by roughly a third, so the limit is deliberately conservative.

Project Structure

mcp-vision-server/
├── pyproject.toml
├── .env.example
├── .gitignore
├── README.md
├── LICENCE
└── src/
    └── mcp_vision_server/
        ├── __init__.py
        └── server.py

License

MIT — do whatever.

Available Tools

1 tool
describe_imageA

Pass a local image file to a vision-capable AI and get back a text description.

IMPORTANT: The image parameter MUST be a local absolute file path on disk. Do NOT pass URLs, base64 strings, or data URIs — always provide the full absolute path to an image file (e.g. "C:\Users\photos\cat.jpg" or "/home/user/images/pic.png"). Supported formats: PNG, JPG, JPEG, GIF, WEBP.

Parameters: image (str, required): Local absolute file path to the image. prompt (str, optional): Instruction for the vision model. Defaults to 'Describe this image in detail.'

Returns: Text description produced by the vision model.

ParametersJSON Schema
NameRequiredDescriptionDefault
imageYesLocal absolute file path to the image (e.g. C:\Users\photos\cat.jpg). MUST be a real file on disk — not a URL, not base64.
promptNoInstruction for the vision model.Describe this image in detail.

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the operation (pass to vision model, get description) and return semantics, but omits error handling, permissions, rate limits, or what happens if the file is missing. This is adequate but not thorough.

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 well-structured, starting with a clear one-sentence purpose, followed by an important usage note, parameter list, and return value. Each section is relevant and front-loaded, with no redundant filler.

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 no annotations, output schema, or siblings, the description covers purpose, parameters, constraints, and return value. It is reasonably complete for an agent to select and invoke the tool correctly, though it could mention error conditions or use cases more explicitly.

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 already covers both parameters with 100% coverage, including descriptions. The description adds examples of valid paths and reiterates the local-path constraint, which is mildly helpful but does not introduce new semantics 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 states the tool's function with a specific verb and resource: pass a local image file to a vision-capable AI and get back a text description. It is unambiguous and distinguishes itself from any potential sibling tools by focusing on local image file input.

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 usage constraints: local absolute path only, no URLs or base64, supported formats, and an optional prompt with default. While no sibling tools exist to contrast, the when-not guidance is clear and actionable.

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. 1 tool updatev0.1.0
    • First observeddescribe_image

TDQS

A4.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. The tool's purpose is uniquely defined.

Naming Consistency5/5

The single tool follows a clear verb_noun pattern (describe_image), which is consistent and descriptive.

Tool Count3/5

A single tool is on the thin side, but reasonable for a narrowly scoped vision-description server. It feels minimal but not trivial.

Completeness5/5

The tool fully covers the server's stated purpose of describing images from local files, with no obvious missing operations for that domain.

Maintenance

ActivityMaintained
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/joshsssn/mcp-vision-server'

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