mcp-vision
提供图片识别和OCR功能,可配置使用OpenAI的视觉模型(如gpt-4o)进行图像描述和文字提取。
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-vision请描述这张图片的内容"
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.
mcp-vision
通过 火山引擎方舟 视觉模型(doubao-seed-2.0-pro)为无视觉能力的主模型提供识图能力的 MCP 服务器。
主模型(如 GLM-5.2)调用本 MCP 提供的工具,把图片交给视觉模型,拿到文字描述回填到对话中,从而间接获得「看图」能力。
跨平台支持 macOS / Linux / Windows,配置路径与工具行为一致。
提供的工具
工具 | 作用 |
| 通用识图:描述图片内容(文字/物体/人物/场景/布局/颜色),prompt 可定制 |
| 纯文字提取:只返回图片中的文字,保持排版,不描述图像本身 |
两个工具的 image 参数统一支持三种形式:
本地文件路径:
/tmp/screenshot.png、./pic.jpghttp(s) URL:
https://example.com/a.pngbase64 字符串:裸串即可,无需
data:前缀
Related MCP server: multimodal-proxy
安装
macOS / Linux
cd mcp-vision
python3 -m venv .venv
.venv/bin/pip install -e .Windows(PowerShell)
cd C:\Users\<你的用户名>\mcp-vision
python -m venv .venv
.venv\Scripts\pip install -e .安装后生成两个可执行命令:
mcp-vision(MCP 服务器)和vision-config(可视化配置工具)。 macOS/Linux 位于.venv/bin/,Windows 位于.venv\Scripts\(带.exe后缀)。
依赖与版本要求
venv 和 pip 都是 Python 标准库自带,无需额外安装任何工具,只要有 Python 即可。项目直接依赖只有 2 个第三方包:
依赖 | 推荐版本(已验证可用) | 最低版本 | 说明 |
Python | 3.14.6 | 3.10 |
|
mcp | 1.28.1 | 1.2.0 | MCP SDK( |
httpx | 0.28.1 | 0.27.0 | 调用视觉模型 HTTP 接口 |
其余包(anyio、pydantic、uvicorn、starlette 等)均为
mcp的传递依赖,安装时自动拉取,无需手动指定版本。 配置工具vision-config的 Web 服务使用 Python 标准库http.server,不依赖 Flask 或任何第三方 Web 框架。
配置(统一在 opencode.json 管理)
视觉模型的 model / baseURL / key 全部由 ~/.config/opencode/opencode.json 的
mcp.vision.environment 注入,切换平台时只改这一个文件,无需建 .env、无需动代码。
环境变量 | 含义 | 必填 |
| 视觉模型凭据 | 是 |
| OpenAI 兼容接入点( | 是 |
| 视觉模型 id | 是 |
| 单次识别最大输出 token(默认 2048) | 否 |
| 请求超时秒数(默认 60) | 否 |
接入 opencode
在 ~/.config/opencode/opencode.json 顶层增加 mcp 字段(三个核心变量都在 environment 里):
{
"mcp": {
"vision": {
"type": "local",
"command": ["/<你的路径>/mcp-vision/.venv/bin/mcp-vision"],
"enabled": true,
"environment": {
"ARK_API_KEY": "ark-你的key",
"ARK_BASE_URL": "https://ark.cn-beijing.volces.com/api/plan/v3",
"VISION_MODEL": "doubao-seed-2.0-pro"
}
}
}
}切换平台示例
只改 environment 三个值,重启 opencode 生效:
// 换到 OpenAI 官方
"environment": {
"ARK_API_KEY": "sk-你的openai-key",
"ARK_BASE_URL": "https://api.openai.com/v1",
"VISION_MODEL": "gpt-4o"
}
// 换到阿里通义千问 VL
"environment": {
"ARK_API_KEY": "sk-你的dashscope-key",
"ARK_BASE_URL": "https://dashscope.aliyuncs.com/compatible-mode/v1",
"VISION_MODEL": "qwen-vl-max"
}前提:目标接口需兼容 OpenAI
/chat/completions+image_url格式。
Windows 上的 command 路径
Windows 的 venv 可执行文件在 Scripts 目录且带 .exe 后缀。JSON 中的路径可用正斜杠 /(推荐,免转义)或双反斜杠 \\:
// 写法一:正斜杠(推荐,无需转义)
"command": ["C:/Users/<你的用户名>/mcp-vision/.venv/Scripts/mcp-vision.exe"]
// 写法二:双反斜杠
"command": ["C:\\Users\\<你的用户名>\\mcp-vision\\.venv\\Scripts\\mcp-vision.exe"]opencode 全平台统一使用
~/.config/opencode/opencode.json作为全局配置。 Windows 上即C:\Users\<用户名>\.config\opencode\opencode.json,与 macOS/Linux 路径结构一致,无需额外设置。
若未 pip install -e .,也可直接用 python 运行:
"command": ["python3", "-m", "mcp_vision.server"](需把 src 加入 PYTHONPATH,或在项目目录下运行)
接入后,主模型即可在需要看图时自动调用 recognize_image / ocr_image。
可视化配置工具(vision-config)
配套的本地 Web 工具,浏览器里编辑三个变量、一键切预设平台、测试连接、保存写回 opencode.json(带备份)。
macOS / Linux
.venv/bin/vision-config # 默认 http://127.0.0.1:7788,自动开浏览器
PORT=8000 .venv/bin/vision-config # 换端口Windows(PowerShell)
.venv\Scripts\vision-config.exe # 默认 http://127.0.0.1:7788,自动开浏览器
$env:PORT=8000; .venv\Scripts\vision-config.exe # 换端口功能:
预设平台一键填充:火山引擎 / OpenAI / 通义千问 / 智谱 GLM-4V / 自定义
测试连接:用当前填的 model+baseURL+key 发一张测试图,验证视觉接口可用并返回识别结果
保存写回:写入 opencode.json 的
mcp.vision.environment,保存前自动备份为opencode.json.vision-bak-时间戳key 安全:脱敏显示,未改动则保留原值,不会被脱敏串覆盖
只绑 127.0.0.1:不暴露外网
保存后需重启 opencode 让 MCP 子进程读到新配置。
命令行自测
# 单独跑 stdio server(会阻塞等待 MCP 客户端握手)
mcp-vision开发
python -c "import mcp_vision.server" # 导入自检
python -m py_compile src/mcp_vision/server.pyAvailable Tools
2 toolsocr_imageA
提取图片中的所有文字内容(OCR),保持原始排版。
与 recognize_image 的区别:本工具只提取文字,不描述图像本身, 适合截图取字、票据/单据录入、文档数字化等场景。
Args: image: 图片来源,支持本地路径 / http(s) URL / base64 字符串。
Returns: 图片中识别到的纯文本内容。
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述说明了行为(提取文字、保持排版),但未提及权限、副作用或结果格式等,在没有注解的情况下基本充分但不够详尽。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
描述简洁,先总述用途,再区分同族工具,最后说明参数和返回,无冗余内容。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
针对单一参数和简单返回值,描述充分解释了输入输出,无需额外补充。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
解释了image参数支持的类型(本地路径、URL、base64),超越了模式中仅字符串类型的定义,覆盖了参数。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
明确说明了OCR提取文字功能,并与recognize_image区分,使用了具体动词+资源(提取文字),场景清晰。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
通过对比recognize_image和列举适用场景(截图取字、票据录入等)提供了使用指引,但未明确说明何时不应使用。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recognize_imageA
识别图片内容并返回文字描述。
适用于截图分析、UI 审查、图片内容理解、图表解读等场景。
Args: image: 图片来源,支持三种形式: 1. 本地文件绝对/相对路径(如 /tmp/a.png、./pic.jpg) 2. http(s) 网络图片 URL 3. base64 编码字符串(裸串即可,无需 data: 前缀) prompt: 想让模型关注的重点或要回答的问题。 默认为详细描述图片全部内容。
Returns: 视觉模型给出的图片文字描述。
Raises: FileNotFoundError: 本地图片路径不存在。 RuntimeError: 未配置 API key 或视觉模型调用失败。
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | ||
| prompt | No | 请详细描述这张图片的内容,包括其中的文字、物体、人物、场景、布局、颜色等信息。 |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 error conditions (FileNotFoundError, RuntimeError) and parameter behaviors (image source types, prompt default), adding useful context. It does not mention any destructive behavior, which is appropriate. Could further explain model dependencies or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Raises) and bullet points. Every sentence adds value, and there is no redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (mentioned), the description covers return values and error cases. It addresses parameter details and usage scenarios thoroughly. No critical information is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates. It explains the 'image' parameter can be local path, URL, or base64, and describes 'prompt' as optional with a default. This adds significant meaning beyond the schema's bare definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recognizes image content and returns a textual description. It uses specific verbs and resources, and implicitly distinguishes from sibling 'ocr_image' by focusing on general image understanding rather than just OCR.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists applicable scenarios (screenshot analysis, UI review, etc.), providing implicit usage guidance. However, it does not explicitly state when not to use the tool or contrast it with alternatives. The sibling tool 'ocr_image' is not mentioned, missing an opportunity for clear differentiation.
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.
2 tool updates
v0.1.0- First observed
ocr_image - First observed
recognize_image
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: ocr_image extracts text only, while recognize_image describes image content. The descriptions explicitly contrast them, leaving no ambiguity.
Both tools follow a consistent verb_noun snake_case pattern: 'ocr_image' and 'recognize_image'. This creates a predictable and clear naming convention.
With only 2 tools, the server feels minimal for a vision-focused service. While the tools cover basic OCR and general image recognition, the count is on the low end for the domain.
The server provides core text extraction and image description, but lacks other common vision operations like object detection, image generation, or format conversion. The surface is adequate for narrow use cases but not comprehensive.
Maintenance
Related MCP Connectors
MCP server for Qwen Image 3 AI image generation
MCP server for ByteDance Seedream AI image generation
MCP server for Hailuo (MiniMax) AI video generation
MCP server for AI dialogue using various LLM models via AceDataCloud
Related MCP Servers
- AlicenseAqualityDmaintenanceMCP server integrating VolcEngine's image generation capabilities, enabling text-to-image, image-to-image, and image set generation for AI applications.426 npmMIT
- AlicenseNot gradedqualityDmaintenance为纯文本主模型提供多模态能力的MCP服务器,通过外包图像、视频和音频分析给外部多模态模型并回填文字结果。2MIT
- AlicenseNot gradedqualityCmaintenanceMCP 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.4 npmApache 2.0
- AlicenseAqualityBmaintenanceA local MCP server that gives vision to vision-less LLMs by describing images and extracting text via Alibaba DashScope vision models.2MIT