Which integrations are available for this server?

Provides tools to describe images, extract text (OCR), answer questions about images, and process images from the macOS clipboard by delegating to local vision models running on Ollama.

How do I use ollama-vision-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., "@ollama-vision-mcp Describe the clipboard image" 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.

ollama-vision-mcp

by ducnm9

Overview Schema Related Servers Score Discussions

Python

Local

Vision MCP Server

MCP server for image processing via Ollama vision models (Gemma 4, Gemma 3, LLaVA...).
Enables LLM clients without vision capability (DeepSeek, Qwen, etc.) to process images by delegating to a local vision model through Ollama.

Features

Tool	Description
`describe_image`	Describe image content (brief / detailed / exhaustive)
`ocr_image`	Extract text from image with language hints (vi, en, ja, zh, ko)
`ask_image`	Ask any question about an image with a custom prompt
`process_clipboard_image`	Read image directly from macOS clipboard — no file path needed

Related MCP server: mcp-vision

Requirements

macOS (clipboard tool uses osascript)
Python 3.12+
uv — Python package manager
Ollama — local LLM runtime

Installation

1. Clone the repo

git clone https://github.com/nguyenduc/vision-mcp-server.git
cd vision-mcp-server

2. Install dependencies

uv sync

uv sync creates .venv/ and installs all packages from uv.lock. No need for pip install or uv init.

3. Pull a vision model

ollama pull gemma4

Other compatible vision models: gemma3, llava, llava-llama3, moondream.

4. Make sure Ollama is running

ollama serve

Verify:

curl http://127.0.0.1:11434/api/tags

5. Test the server

uv run server.py

The server runs over stdio — press Ctrl+C to stop.

MCP Client Configuration

OpenCode

Add to .opencode.json (project-level or ~/.opencode.json):

{
  "mcpServers": {
    "vision": {
      "enabled": true,
      "type": "local",
      "command": ["uv", "run", "server.py"],
      "cwd": "/absolute/path/to/vision-mcp-server",
      "env": ["OLLAMA_BASE_URL=http://127.0.0.1:11434", "VISION_MODEL=gemma4"]
    }
  }
}

Note: In OpenCode, command is an array and env is an array of "KEY=VALUE" strings, not an object.

Claude Desktop

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

{
  "mcpServers": {
    "vision": {
      "command": "uv",
      "args": ["run", "server.py"],
      "cwd": "/absolute/path/to/vision-mcp-server"
    }
  }
}

Cursor / Windsurf / Cline

{
  "mcpServers": {
    "vision": {
      "command": "uv",
      "args": ["run", "server.py"],
      "cwd": "/absolute/path/to/vision-mcp-server",
      "env": {
        "OLLAMA_BASE_URL": "http://127.0.0.1:11434",
        "VISION_MODEL": "gemma4"
      }
    }
  }
}

Environment Variables

Variable	Default	Description
`OLLAMA_BASE_URL`	`http://127.0.0.1:11434`	Ollama API endpoint
`VISION_MODEL`	`gemma4`	Model name in Ollama (must have vision capability)

How It Works

┌─────────────┐     ┌───────────────────┐     ┌─────────────┐
│  LLM Client │────▶│  Vision MCP Server │────▶│   Ollama    │
│ (DeepSeek)  │◀────│   (stdio/MCP)      │◀────│  (Gemma 4)  │
└─────────────┘     └───────────────────┘     └─────────────┘
      │                       │
      │ [Image 1] + prompt    │ osascript: clipboard → PNG
      │                       │ base64 → /v1/chat/completions
      ▼                       ▼
  Receives text           Returns vision
  description/OCR         analysis result

Clipboard flow: User pastes image → LLM calls process_clipboard_image → server grabs image from macOS clipboard via osascript → encodes to base64 → sends to Ollama → returns text.

File path flow: User provides path → LLM calls describe_image / ocr_image / ask_image with path → server reads file → encodes → sends to Ollama → returns text.

Troubleshooting

Error	Cause	Fix
`404 Not Found`	Model doesn't exist in Ollama	`ollama pull gemma4`
`Connection refused`	Ollama is not running	`ollama serve`
`No image found in clipboard`	Clipboard is empty or not an image	Copy an image to clipboard first
Timeout	Model too large for hardware	Switch to a smaller model: `moondream`

License

MIT

Available Tools

4 tools

ask_imageB

Ask any question about an image.

Args: image_path: Absolute path to the image file question: Your question or prompt about the image

ParametersJSON Schema

Name	Required	Description	Default
`question`	Yes
`image_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description is too minimal to disclose behavioral traits. It does not mention limitations (e.g., image formats, size), network usage, or what happens with the image. The agent gets no insight into side effects or requirements beyond the bare function.

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 and front-loaded. The first sentence states the purpose, and the Args section clearly lists parameters with brief explanations. No wasted words or redundant content.

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?

Despite having an output schema, the description is incomplete for a tool with no annotations. It does not mention expected output structure, error conditions, or any constraints. Given the sibling tools, it also fails to position itself contextually. The description is adequate for the simplest case but lacks depth.

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?

The schema provides only parameter titles with 0% description coverage. The description adds meaningful semantics: 'Absolute path to the image file' clarifies that image_path must be filesystem-absolute, and 'Your question or prompt about the image' clarifies the question parameter. This compensates well for the lack of schema descriptions.

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 'Ask any question about an image' clearly states the tool's function with a specific verb and resource. It distinguishes itself implicitly from sibling tools like describe_image and ocr_image by focusing on arbitrary questions, though it does not explicitly differentiate them.

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?

There is no guidance on when to use this tool versus alternatives such as describe_image or ocr_image. The description simply states what it does without any prerequisites, exclusions, or context for choosing it.

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

describe_imageA

Describe the content of an image file.

Args: image_path: Absolute path to the image file (png, jpg, webp, gif) detail_level: Level of detail - "brief", "detailed", or "exhaustive"

ParametersJSON Schema

Name	Required	Description	Default
`image_path`	Yes
`detail_level`	No		detailed

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/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. It implies a read-only operation but doesn't explicitly state side-effect-free behavior or limitations. It does list acceptable file formats and detail levels, providing some transparency.

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 compact and well-structured: a clear one-sentence purpose followed by an Args block. Every line is informative, and the format is easy to scan.

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 fully specifies the tool's inputs and purpose, which is sufficient for a straightforward 2-parameter read-only tool. Output semantics are handled by the output schema. It doesn't reference sibling tools, but that gap is captured in usage_guidelines.

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 0%, so the description compensates by explaining both parameters. image_path specifies absolute path and supported formats, and detail_level enumerates the allowed values. This adds meaningful context beyond the raw schema.

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's function: describing the content of an image file. The verb 'describe' and resource 'image file content' distinguish it from sibling tools like ocr_image or ask_image, though it doesn't explicitly name those alternatives.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus the sibling tools (ocr_image, ask_image, process_clipboard_image). The description only lists the arguments and their meanings, leaving the agent to infer usage context.

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

ocr_imageA

Extract all visible text from an image (OCR).

Args: image_path: Absolute path to the image file language: Primary language hint - "auto", "vi", "en", "ja", "zh", "ko"

ParametersJSON Schema

Name	Required	Description	Default
`language`	No		auto
`image_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/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 carry the behavioral transparency burden. It only states the core action and language parameter, but omits details such as supported image formats, error behavior, limitations, or permission requirements. This leaves the agent with little beyond the raw function purpose.

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 compact and front-loaded: one sentence for the purpose plus a short Args list. Every sentence adds useful information and there is no 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 OCR tool with an output schema present, the description covers the primary behavior, arguments, and language scope. The main gap is the lack of explicit guidance on when to choose this tool over sibling image tools, but overall it is sufficiently complete for the tool's complexity.

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?

The input schema has 0% description coverage, but the description compensates well by explaining image_path as an absolute path and language as a hint with explicit supported values. It does not mention that language is optional or how auto-detection interacts, so it is not perfect.

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 uses a specific verb and resource: 'Extract all visible text from an image (OCR)'. This clearly distinguishes it from sibling tools like describe_image or ask_image, which serve different purposes.

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 use when text extraction from images is needed, but it never explicitly states when to use this tool versus sibling tools, nor does it mention any exclusions or alternatives. The absence of explicit guidance makes it only minimally useful.

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

process_clipboard_imageA

Process an image from the macOS clipboard. Call this when user pastes an image or sends [Image] without a file path.

IMPORTANT: Call this tool whenever you see [Image 1], [Image 2], or the user pastes an image from clipboard. The primary model has no vision capability — this tool reads the image from clipboard and analyzes it.

Args: task: Processing type - "describe" (describe image), "ocr" (extract text), or any custom question about the image

ParametersJSON Schema

Name	Required	Description	Default
`task`	No		describe

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. It discloses that the primary model has no vision capability and that the tool reads the clipboard image and analyzes it, which is essential context. It doesn't mention edge cases like empty clipboard, but for a read/analyze operation, the core behavior is transparent.

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 compact and front-loaded with the core purpose. The 'IMPORTANT' repetition and Args section are slightly redundant but not bloated. Overall structure is logical 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?

For a simple one-parameter tool with an output schema, the description covers purpose, usage triggers, and parameter semantics well. It lacks explicit error behavior (e.g., no image on clipboard) and doesn't name sibling tools for file-based images, but it is sufficient for an agent to invoke it correctly.

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

Parameters5/5

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

The schema provides 0% parameter descriptions, but the description compensates fully by explaining the 'task' parameter: 'describe', 'ocr', or any custom question, plus the default value. This gives practical usage semantics beyond the bare 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 uses a specific verb ('process') with a specific resource ('image from the macOS clipboard') and clearly states what it does: reads and analyzes clipboard images. It differentiates from siblings by specifying 'without a file path' and 'paste from clipboard', making the scope unambiguous.

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 explicit trigger conditions: 'Call this whenever you see [Image 1]... or the user pastes an image from clipboard.' It also implies when-not by saying 'without a file path', but it does not explicitly name alternative sibling tools for file-based images. This is clear context with a minor omission.

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.

4 tool updatesv1.0.0Aug 2, 2026
- First observedask_image
- First observeddescribe_image
- First observedocr_image
- First observedprocess_clipboard_image

Install Server

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

TDQS

A3.6/5.0

Disambiguation3/5

describe_image and ask_image both handle arbitrary image analysis, and process_clipboard_image explicitly supports describe/ocr/custom-question tasks, creating overlap. However, the input-source distinction (file vs clipboard) reduces ambiguity, and ocr_image is clearly distinct.

Naming Consistency4/5

Three tools follow a consistent verb_noun pattern (describe_image, ocr_image, ask_image), and process_clipboard_image also uses verb_noun but adds a modifier. The naming is mostly consistent and predictable.

Tool Count4/5

4 tools is a reasonable size for a vision-focused server, covering core operations without being bloated. It could have been higher if not for the redundancy between clipboard and file-based tools.

Completeness4/5

The toolset covers the main vision tasks (description, OCR, custom Q&A) and handles both file and clipboard inputs. Minor gaps like batch processing or image comparison are not essential for the stated purpose.

Maintenance

ActivitySlowing

ResponsivenessNo issues

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

Frenchie A
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72
mcp-qwen-imageOAuth
io.github.AceDataCloud
MCP server for Qwen Image 3 AI image generation
AI & Machine Learning Image & Video Processing
1
OpenAI Tools MCP Server B
ai.com.mcp
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Image & Video Processing Audio Processing Multimedia Processing
927
clipkit A
dev.clipkit
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Multimedia Processing Image & Video Processing
15215

Related MCP Servers

llm-vision-mcp
AI & Machine Learning Image & Video Processing
ghbalf
A
license
Not graded
quality
C
maintenance
An MCP server that enables any LLM to describe images from file paths, URLs, or base64 data by forwarding them to a supported vision provider such as OpenAI, Anthropic, or local Ollama models.
Updated 5 months ago (2026-04-21 22:53 UTC)
1,060
10
MIT
mcp-vision
Image & Video Processing AI & Machine Learning
MikeyBeez
F
license
A
quality
D
maintenance
MCP server for vision capabilities, enabling screenshot, camera, and image analysis using Ollama vision models.
Updated 8 months ago (2026-01-14 19:30 UTC)
4
1
-
llm-vision
Image & Video Processing AI & Machine Learning
maple-red
A
license
Not graded
quality
C
maintenance
MCP server that provides a 'borrowed eye' for text-only LLMs, enabling them to identify and describe local images via the Qwen VL vision model, including face recognition, scene description, OCR, and targeted visual questioning.
Updated a month ago (2026-08-05 13:12 UTC)
3
Apache 2.0
local-vision-mcp
AI & Machine Learning Image & Video Processing
tmchao7
A
license
Not graded
quality
B
maintenance
MCP server for local Ollama vision analysis, enabling text-only agents like Claude Code to inspect images via a single tool. Processes images locally with Ollama, keeping image bytes on the machine and returning text reports.
Updated a month ago (2026-08-06 02:15 UTC)
2
MIT

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/ducnm9/ollama-vision-mcp'

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