de en es ja ko ru zh

ollama-vision-mcp

Name: ollama-vision-mcp
Author: masterLazy

by masterLazy

Overview Schema Source Related Servers Discussions Admin

Python

Local

ollama-vision-mcp

English · 中文

VS Code Copilot가 텍스트 전용 모델(예: DeepSeek)을 사용할 때 로컬 비전 기능을 제공하는 최소한의 브리징 서비스입니다.

Copilot이 텍스트 전용 모델을 사용하면 이미지를 직접 "볼" 수 없습니다. 이 MCP 서버는 그 공백을 메웁니다. 폴더에 스크린샷을 넣으면 Copilot이 이 브리지를 통해 이미지를 읽고, 로컬 Ollama 비전 모델에 보내며, 텍스트 전용 모델이 이해할 수 있는 텍스트 설명을 받아옵니다.

VS Code Copilot Chat (Agent mode, text-only model)
        │  MCP stdio
        ▼
ollama-vision-mcp (this package)
        │  Read local image → base64 → POST /v1/chat/completions
        ▼
Ollama (local vision model, e.g., qwen2.5vl:7b)

도구

도구	매개변수	설명
`describe_image`	`path` (required), `mode?`, `question?`	이미지를 읽고 텍스트 설명을 생성합니다. `mode`는 선택 사항이며: `general`(기본값), `ocr`, `ui`, `diagram`입니다. `question`은 추가 질의를 제공할 수 있습니다.
`list_images`	`directory?` (default: inbox directory)	읽을 수 있는 이미지 파일을 나열합니다.
`extract_text`	`path` (required)	OCR을 통해 이미지에서 텍스트를 추출합니다.
`vision_status`	—	현재 구성, Ollama 연결 상태, 사용 가능한 모델 목록을 표시합니다.

Related MCP server: Hybrid Vision MCP Server

이 도구의 범위

이 패키지는 단지 브리지 계층입니다. Ollama와 순수하게 HTTP(OpenAI 호환 /v1/chat/completions 및 /v1/models)로 통신합니다.

다음은 처리하지 않습니다:

Ollama 설치, ollama serve 시작, 모델 가져오기, 모델 구성 관리;
클립보드 접근, IDE 내부 메커니즘, 로컬 Ollama 외의 네트워크 서비스 접근.

Ollama 설치 및 모델 가져오기는 전적으로 사용자 책임입니다(전제 조건 참조).

전제 조건

다음은 직접 설정해야 합니다:

Python 3.10+
Ollama가 설치되어 실행 중이어야 함: ollama serve
비전 모델을 하나 이상 가져와야 합니다. 권장 사항:
bash
```
ollama pull qwen2.5vl:7b
```
기타 옵션: qwen3-vl:8b, gemma3:12b, llama3.2-vision:11b, llava:7b. GPU에 적합한 모델을 선택하고, 나중에 VISION_MCP_MODEL 환경 변수로 지정하세요.

🚀 빠른 설치 (권장)

저장소 루트에서 단일 명령을 실행하여 설치 및 구성을 완료하세요:

bash

cd ollama-vision-mcp
python setup_mcp.py

스크립트는 자동으로 다음을 수행합니다:

전용 가상 환경(.venv)을 만들고 이 패키지를 설치합니다(전역 환경을 오염시키지 않음).
로컬 Ollama 서비스를 감지하고 사용 가능한 비전 모델을 나열합니다.
base_url, model, inbox, max_tokens, 이미지 압축, 선택적 API 키를 대화형으로 안내합니다.
구성을 프로젝트의 .vscode/mcp.json 및/또는 사용자 수준의 전역 MCP 파일(%APPDATA%\Code\User\mcp.json)에 기록합니다. 기존 설정과 병합하며 다른 MCP 서버를 덮어쓰지 않습니다.

비대화형 사용(CI/스크립트에 적합):

bash

python setup_mcp.py --yes --project --model qwen2.5vl:7b
python setup_mcp.py --print         # Only prints the config JSON, does not write to file

설치 후 VS Code에서 창 다시 로드(Ctrl+Shift+P → “Developer: Reload Window”)를 실행하여 구성을 적용하세요.

이전에 실행한 적이 있다면 ollama-vision-setup 명령만으로 다시 구성할 수도 있습니다.

설치 확인

VS Code Copilot Chat(에이전트 모드)에서 다음을 입력하세요:

text

Run vision_status

반환된 JSON에 "ollama": { "ok": true, ... } 및 모델 목록이 포함되어 있으면 연결이 성공한 것입니다. ok가 false이면 먼저 Ollama(ollama serve)를 시작한 후 다시 시도하세요.

사용 방법

프로젝트의 받은 편지함 디렉터리(기본값 .ai/inbox)에 스크린샷을 넣으세요. 서버는 필요할 때 이 디렉터리를 자동으로 생성합니다.
Copilot Chat에서 예를 들어 다음과 같이 질문하세요:
“받은 편지함의 스크린샷을 보고 이 오류가 무엇에 관한 것인지 알려주세요.”
에이전트는 자동으로 list_images → describe_image를 호출하고 텍스트 설명을 기반으로 답변합니다.

에이전트를 더 똑똑하게 만들기(선택 사항): 준비된 지시 파일 .github/instructions/ollama-vision/vision-tools.instructions.md을 프로젝트의 동일한 경로에 복사하세요. 이 파일은 에이전트에게 전체 비전 워크플로우(호출 순서 list_images → describe_image → extract_text, 모드 선택, 문제 해결, 받은 편지함에 스크린샷을 넣도록 안내하는 방법)를 가르칩니다. VS Code 파일 지시사항으로서 이미지와 관련된 작업이 있을 때마다 필요 시 발견되므로 별도 설정 없이 바로 사용할 수 있습니다.

환경 변수 참조

변수	기본값	설명
`VISION_MCP_BASE_URL`	`http://localhost:11434/v1`	Ollama의 OpenAI 호환 기본 URL
`VISION_MCP_MODEL`	`qwen2.5vl:7b`	사용할 비전 모델
`VISION_MCP_API_KEY`	empty (actually uses `ollama`)	API 키(Ollama에서 무시됨)
`VISION_MCP_INBOX`	`.ai/inbox`	`list_images`의 기본 디렉터리
`VISION_MCP_MAX_TOKENS`	`2048`	비전 모델의 최대 출력 토큰 수
`VISION_MCP_COMPRESS`	`1`	이미지가 50KB를 초과하면 자동으로 768px JPEG로 크기 조정
`VISION_MCP_THINK`	`0`	thinking 모델에 대해 thinking을 활성화(`1`)하거나 `reasoning_effort=none`으로 비활성화(`0`, 기본값)

호환 별칭: VISION_MODEL, VISION_BASE_URL, VISION_INBOX, VISION_API_KEY.

수동 설치 (대안)

각 단계를 완전히 수동으로 제어해야 하는 경우 아래 과정을 참조하세요.

1. 환경 생성 및 설치

bash

cd ollama-vision-mcp
python -m venv .venv
.venv\Scripts\activate          # Windows
# source .venv/bin/activate    # macOS / Linux
pip install -e .

설치 후 두 가지 명령을 사용할 수 있습니다:

ollama-vision-mcp — MCP 서버 시작
ollama-vision-setup — 대화형 구성 단축키

2. VS Code 등록

프로젝트의 .vscode/mcp.json(프로젝트 전용) 또는 사용자 수준 파일 %APPDATA%\Code\User\mcp.json(모든 프로젝트)에 다음을 복사하세요. command를 가상 환경의 Python 인터프리터 절대 경로로 변경해야 합니다:

json

{
  "servers": {
    "ollama-vision": {
      "type": "stdio",
      "command": "D:/MyRepos/ollama-vision-mcp/.venv/Scripts/python.exe",
      "args": ["-m", "ollama_vision_mcp"],
      "env": {
        "VISION_MCP_BASE_URL": "http://localhost:11434/v1",
        "VISION_MCP_MODEL": "qwen2.5vl:7b",
        "VISION_MCP_INBOX": ".ai/inbox"
      }
    }
  }
}

⚠️ command는 가상 환경 내부의 Python 인터프리터에 대한 절대 경로여야 합니다. ollama-vision-setup --project를 실행하여 이 파일을 자동으로 생성할 수도 있습니다. 서버는 호출될 때 os.getcwd()를 사용하므로 상대 경로(path 및 받은 편지함 디렉터리 등)는 서버가 시작된 프로젝트 루트를 기준으로 확인됩니다.

스모크 테스트

다음 스크립트를 실행하여 Ollama 연결을 확인하고 받은 편지함 내용을 나열한 후 첫 번째 이미지에 실제 비전 호출을 수행하세요:

bash

python examples/smoke_test.py

라이선스

MIT

Available Tools

4 tools

describe_imageA

Read a local image and return a text description from the local Ollama vision model.

Use when the user references a screenshot or image you cannot see. path is absolute, or relative to the project directory.

Name	Required	Default
`mode`	No	general
`path`	Yes
`question`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the local Ollama model and path semantics, but does not explain behavior around missing files, model limitations, or the purpose of mode/question parameters.

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 three sentences, front-loaded with the core purpose, followed by usage context and path semantics. Every sentence adds value with no 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?

Although an output schema exists, the description omits crucial parameter semantics for `mode` and `question`, which directly affect tool behavior. Without these details, an agent cannot fully understand how to use the tool for specialized cases like OCR or diagram analysis.

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 0%, so the description must compensate. It explains only the `path` parameter ('absolute, or relative to the project directory'), leaving `mode` and `question` completely unexplained. This is a significant gap for a tool with three parameters.

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 'Read a local image and return a text description from the local Ollama vision model.' This specifies the action, resource, and method, and distinguishes it from siblings like extract_text by focusing on generating a description rather than extracting text.

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 guidance: 'Use when the user references a screenshot or image you cannot see.' This gives a clear condition for use, though it does not explicitly mention alternatives or when not to use.

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

extract_textA

Extract all visible text (OCR) from a local image verbatim.

Use for code screenshots, terminal output, or error dialogs.

Name	Required	Description	Default
`path`	Yes

Output 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 full responsibility for behavioral disclosure. It states that OCR is used, that all visible text is extracted, and that output is verbatim, which are meaningful behavioral traits. It does not cover failure modes or image format limitations, but the core behavior is clearly 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 two short sentences with no redundancy. The first sentence states the action and scope, and the second lists concrete use cases. Every word earns its place.

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 single-parameter tool with an output schema and no complex side effects, the description covers the essential operational context: what it does, when to use it, and the key behavioral constraint (verbatim OCR). It is not exhaustive but adequately complete for its low 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?

Schema description coverage is 0%, but the only parameter is 'path' and the description's phrase 'from a local image' clearly establishes that path refers to a local image file. This compensates for the lack of schema documentation, though it does not specify path syntax or accepted formats.

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 starts with a specific verb and resource: 'Extract all visible text (OCR) from a local image verbatim.' It clearly distinguishes this tool from siblings like describe_image by focusing on text extraction rather than image description, and adds qualifiers ('all visible', 'verbatim') that make the scope precise.

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 second sentence gives concrete use cases: 'Use for code screenshots, terminal output, or error dialogs.' This provides clear context for when to use the tool, though it does not explicitly mention alternatives or exclusions relative to sibling tools.

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

list_imagesA

List image files in a directory.

Defaults to the configured inbox folder where the user drops screenshots. Use this before describe_image to find what is available.

Name	Required	Description	Default
`directory`	No

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior3/5

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

With no annotations, the description must carry behavioral transparency. It discloses the default behavior of falling back to the configured inbox folder, which is valuable. However, it does not specify whether subdirectories are included, result sorting, or other behavioral traits, leaving some gaps.

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 consists of two concise, front-loaded sentences. Every word adds value, with no fluff or repetition.

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 simple listing tool with an output schema present, the description covers purpose, default behavior, and usage guidance. It is sufficiently complete for an agent to correctly select and invoke the 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?

The schema describes the 'directory' parameter only as an optional string/null with no description. The tool description compensates by explaining that omitting the directory defaults to the configured inbox folder, adding meaningful semantic content 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 'List image files in a directory' with a specific verb and resource. It also distinguishes from sibling tools by positioning this as a prerequisite for describe_image, making its purpose unambiguous.

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?

Explicitly advises 'Use this before describe_image to find what is available,' giving a clear when-to-use instruction and a named alternative. This effectively communicates the intended workflow without needing to enumerate all siblings.

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

vision_statusA

Show bridge configuration and Ollama connectivity / available models.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

The description indicates a read-only status operation via 'Show', but does not disclose potential error behaviors, such as what happens if Ollama is not reachable, nor does it confirm side-effect-free operation. With no annotations, a bit more detail would be helpful.

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 directly states the tool's purpose. Every word earns its place with no fluff or redundancy.

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 tool's simplicity (zero parameters, output schema present), the description adequately covers its purpose. However, it lacks any usage context or behavioral nuance (e.g., read-only nature, dependency on external services), which would make it fully 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?

The input schema has zero parameters, so there is no parameter semantics to explain. The description adds value by indicating what the tool returns (configuration, connectivity, models), which is sufficient for a no-parameter tool.

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 function with a specific verb ('Show') and resource ('bridge configuration and Ollama connectivity / available models'). This distinguishes it from sibling image processing tools like describe_image and list_images.

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 explicit guidance is given for when to use this tool versus alternatives. The purpose implies a status check, but the description does not state any prerequisites or conditions (e.g., 'Use when checking Ollama availability').

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.

4 tool updatesv0.1.0Aug 1, 2026
- First observeddescribe_image
- First observedextract_text
- First observedlist_images
- First observedvision_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-08-01 13:05 across 4 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: list_images finds images, describe_image provides semantic description, extract_text performs OCR, and vision_status checks configuration. There is no overlap or ambiguity between them.

Naming Consistency4/5

Tool names predominantly follow a verb_noun snake_case pattern (describe_image, list_images, extract_text). The exception is vision_status, which is noun_noun rather than verb_noun, but the inconsistency is minor and the naming style remains uniform.

Tool Count5/5

With 4 tools, the server is well-scoped for a focused vision MCP. Each tool serves a necessary role in the image-analysis workflow, and the count is neither too sparse nor excessive.

Completeness5/5

The tool surface covers the core workflows: discovering available images, getting a semantic description, extracting text, and verifying connectivity. There are no obvious gaps that would prevent an agent from completing typical vision-related tasks.

Maintenance

ActivityInactive

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

FrenchieA
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72
https://mcp.getfrenchie.dev
yourimageshare
io.github.yourimageshare
MCP server exposing the YourImageShare upload API (upload/list/delete) as tools for AI agents.
Cloud Storage Image & Video Processing
11
https://yourimageshare.com/mcp
SubstrateB
co.trysubstrate
Shared memory MCP server for Claude Code, Codex, Gemini CLI and Cursor. Cited, editable.
Developer Tools Knowledge & Memory
131
https://app.trysubstrate.co/mcp
OpenAI Tools MCP ServerB
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
https://openai-tools.run.mcp.com.ai/mcp

Related MCP Servers

ollama-vision-mcp
Image & Video Processing AI & Machine Learning
ducnm9
F
license
A
quality
D
maintenance
MCP server enabling LLM clients without vision capability to process images by delegating to local Ollama vision models. Supports describing images, OCR, asking questions, and processing clipboard images.
Updated 4 months ago (2026-07-06 09:07 UTC)
4
-
Hybrid Vision MCP Server
Image & Video Processing AI & Machine Learning
sameersemna
A
license
Not graded
quality
B
maintenance
Bridges local vision engines (Tesseract.js OCR and Sharp preprocessing) with Ollama vision models for image analysis, comparison, text localization, and browser screenshot annotation over MCP-compliant HTTP/SSE transports.
Updated a month ago (2026-09-29 14:57 UTC)
ISC
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 3 months ago (2026-08-06 02:15 UTC)
2
MIT
fastcar-vision
Image & Video Processing AI & Machine Learning
williamDazhangyu
A
license
A
quality
C
maintenance
Provides vision understanding capabilities such as image analysis, OCR, object localization, and video frame analysis, plus optional image generation and editing, to coding agents via OpenAI-compatible multimodal models. Runs as a local MCP server with HTTP and stdio transports, configurable for clients like Codex, Claude Code, Kimi, and Cursor.
Updated 2 months ago (2026-08-25 03:17 UTC)
3
21 npm
MIT