vision-bridge-mcp
Allows using OpenAI-compatible vision models (e.g., GPT-4o-mini) to analyze images and extract text, providing vision capabilities to text-only AI models via MCP.
Click on "Install 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., "@vision-bridge-mcpUse look_at_image to describe this image: /home/user/photo.jpg"
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.
Vision-Bridge MCP Server 🧿
English | 中文
给不支持多模态的模型(如 DeepSeek、纯文本模型)加一双"眼睛":通过 MCP 暴露 看图 / OCR 工具,底层调用任意 OpenAI 兼容 的视觉大模型(智谱、千问、OpenAI 等), 把图片理解成文字返回给 AI。
你的模型(无视觉)--调用MCP工具--> Vision-Bridge Server --图片--> 视觉大模型
^ 理解图片 |
用户发图片给你 <--返回文字描述<-----------┘<------------------┘✨ 特性
通用 OpenAI 兼容:一套代码,可切换智谱 / 千问 / OpenAI / 任何兼容端点,只改配置不改代码
两个工具:
look_at_image(看图理解)+extract_text_from_image(OCR 逐字转录)图片预处理:自动修正方向、压缩限长、转 JPEG,大图不糊细节
深度思考:智谱模型默认开启 thinking 模式,精度优先
限流重试:429 自动指数退避重试,API 错误原样透传
零成本可选:智谱
glm-4.6v-flash或千问新用户 100 万 token 均可免费使用一键安装:
pip install直装,装完即可用vision-bridge命令
Related MCP server: Vision MCP
🚀 快速开始
方式一:pip 一键安装(推荐)
pip install "vision-bridge-mcp @ git+https://github.com/zgz518/vision-bridge-mcp.git"然后在你的工作目录创建 .env(见配置),验证:
vision-bridge --test # 自检:查看配置和工具
vision-bridge --once /path/to/image.png "有什么" # 命令行单图联调方式二:uv
uv tool install git+https://github.com/zgz518/vision-bridge-mcp
vision-bridge --test方式三:克隆 + 虚拟环境
git clone https://github.com/zgz518/vision-bridge-mcp.git
cd vision-bridge-mcp
python -m venv .venv
# Windows: .venv\Scripts\activate macOS/Linux: source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
python server.py --test方式四:直接把链接发给 AI 助手(最省事)
如果你在用 WorkBuddy / Claude Code / Cursor 等 AI 助手,什么都不用自己做——把下面这条消息发给它即可:
帮我安装并使用这个 MCP 服务器:https://github.com/zgz518/vision-bridge-mcp
AI 会自动完成克隆 / 安装依赖 / 生成配置,并引导你提供 API Key(智谱/千问/OpenAI 任选),最后注册到你的 MCP 客户端。你只需要把 Key 交给它。
⚙️ 配置
复制下面的内容,在你的运行目录新建 .env 文件并粘贴(选一家服务商即可,默认智谱免费版):
# 方式一:智谱(免费,推荐)
# 申请 Key:https://bigmodel.cn 控制台 -> API Keys
VISION_BASE_URL=https://open.bigmodel.cn/api/paas/v4
VISION_API_KEY=你的智谱key
VISION_MODEL=glm-4.6v-flash
# 方式二:阿里云百炼·千问(新用户 100 万 token 免费)
# VISION_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1
# VISION_API_KEY=你的百炼key
# VISION_MODEL=qwen-vl-max
# 方式三:OpenAI
# VISION_BASE_URL=https://api.openai.com/v1
# VISION_API_KEY=sk-xxxx
# VISION_MODEL=gpt-4o-mini服务商速览:
服务商 | VISION_BASE_URL | 模型示例 | 费用 |
智谱(默认) |
|
| 免费 |
阿里云百炼·千问 |
|
| 新用户 100 万 token 免费 |
OpenAI |
|
| 付费 |
pip/uv 安装时,
.env放在你运行vision-bridge命令的目录;clone 时放在项目根目录。 项目内也附有.env.example模板,clone 用户可直接cp .env.example .env使用。
🔌 接入 MCP 客户端
WorkBuddy
编辑 %USERPROFILE%\.workbuddy\mcp.json(不带点前缀),加入:
{
"mcpServers": {
"vision-bridge-mcp": {
"type": "stdio",
"command": "vision-bridge",
"args": []
}
}
}(clone 方式则 command 填 .venv/Scripts/python.exe、args 填 server.py 绝对路径)
保存后:连接器管理 → 右上角【自定义连接器】→ 找到 vision-bridge-mcp → 点「信任」启用。
Claude Code / Cline / Cherry Studio 等
以 Claude Code 为例(.mcp.json 或项目配置):
{
"mcpServers": {
"vision-bridge-mcp": {
"command": "vision-bridge"
}
}
}💡 使用技巧(重要)
纯文本模型(尤其是 DeepSeek 系)有一个通病:上传图片后不主动调工具,反而凭图片路径幻觉出内容。服务器已内置「严禁幻觉」指令,但如果你的模型仍不自动触发,请在客户端的全局指令/人设里加一条常驻规则:
当用户上传或粘贴图片,或消息中出现以 .png/.jpg/.jpeg/.webp/.gif 结尾的本地文件路径时,你必须立即调用 look_at_image 工具,把图片路径作为 image 参数传入。在工具返回结果之前,禁止描述任何图片内容(未调工具就描述 = 幻觉)。用户要求提取图片中的文字时,改调 extract_text_from_image。
或者更简单:每次贴图后附带一句 "看这张图",即可触发。
🛠 工具说明
工具 | 参数 | 用途 |
|
| 看图,返回结构化中文描述 |
|
| OCR,逐字转录图片中的文字 |
⚠️ 注意事项
密钥安全:
.env已被 gitignore 排除,不要把真实 Key 写进任何会提交的文件;限流:免费档模型有速率限制(429),已内置重试;高频使用建议充值升级档位或换用付费模型;
精度:免费版为轻量模型,对细节/计数要求高的场景,换旗舰模型(智谱
glm-4.6v、千问qwen-vl-max)。
📄 License
MIT
Available Tools
2 toolsextract_text_from_imageA
【必须调用】OCR 工具:逐字转录图片中的全部文字(适合截图、文档、代码、票据)。 当用户上传的图片需要提取文字时,必须调用本工具。
Args: image: 图片的本地文件绝对路径或 http(s) 图片 URL。
| 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?
The description discloses the core behavior (OCR, verbatim transcription) and the parameter format, which gives agents some sense of what to expect. However, with no annotations provided, it does not disclose potential limitations (e.g., image format support, accuracy issues) or side effects, leaving a gap in behavioral transparency.
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 short and front-loaded with the tool's purpose and a mandatory-call directive. The Args section is clear and direct. Minor redundancy exists with the '必须调用' phrase appearing twice, but it does not significantly detract from the structure.
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 tool's simplicity (single parameter), the description covers purpose, usage, and parameter semantics well. An output schema exists, so return details are not required. It lacks discussion of edge cases like unsupported image types or error handling, but for a straightforward OCR tool, the description is reasonably complete.
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 provides no description for the 'image' parameter (0% coverage). The description fully compensates by stating the parameter accepts a local absolute file path or an http(s) URL, explicitly defining the valid formats. This is essential for correct invocation.
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 explicitly labels the tool as an OCR tool and states it transcribes all text in an image verbatim, with suitable use cases listed (screenshots, documents, code, receipts). The directive '必须调用' (must call) reinforces its specific role, clearly distinguishing it from the sibling tool 'look_at_image', which handles visual inspection rather than text extraction.
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 provides an explicit when-to-use rule: it must be called whenever a user uploads an image requiring text extraction. However, it does not mention when not to use the tool or explicitly compare it to 'look_at_image', so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
look_at_imageA
【必须调用】理解一张图片的内容并返回文字描述。 当用户上传图片、粘贴截图、或提到图片文件路径时,必须调用本工具, 不要因为自己无法直接看图而拒绝或说"看不到"。
Args: image: 图片的本地文件绝对路径(WorkBuddy 上传/粘贴的图片会保存为本地文件, 直接传入其路径,如 C:/Users/xxx/Pictures/1.png 或 D:/xxx/1.png), 也可以是 http(s) 图片 URL。 prompt: 你想让模型重点关注的问题;留空则给出结构化详细描述。
| 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 behavioral burden. It explains that the tool accepts local paths or URLs, returns a text description, and that the prompt parameter focuses attention. It does not cover error cases or edge limitations, but provides solid transparency for a vision interpretation tool.
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 front-loaded with a mandatory-call marker and purpose, then dives into clear parameter explanations. Every sentence adds value, and the structure is easy to scan.
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?
The description covers the core use cases, parameter semantics, and behavioral expectations. It could be more complete by explicitly addressing sibling tool differentiation and error/limitation scenarios, but it is strong for a moderately simple tool with an output schema.
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?
Schema coverage is 0%, and the description fully compensates. It explains the image parameter with absolute path examples and URL support, and describes the prompt parameter's default behavior. This goes well beyond the bare schema definition.
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's purpose: understand an image and return a text description. It distinguishes itself from the sibling extract_text_from_image by focusing on content understanding rather than text extraction, though it does not explicitly name the sibling.
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 gives explicit when-to-use guidance: when the user uploads/pastes an image or mentions a file path, and even instructs the agent not to refuse. However, it lacks when-not-to-use guidance or explicit mention of the alternative extract_text_from_image.
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
extract_text_from_image - First observed
look_at_image
TDQS
Scored across 2 tools
The two tools have clearly distinct primary purposes: look_at_image for general image understanding and extract_text_from_image for exact OCR transcription. There is a minor overlap when an image contains text, but the explicit OCR tool removes most ambiguity.
Both tool names follow a consistent verb_noun pattern with lowercase snake_case (look_at_image, extract_text_from_image). The naming is predictable and clearly reflects each tool's function.
With only two tools, the server feels minimally scoped. While the narrow focus on vision tasks is reasonable, the count is at the lower boundary and leaves the set feeling thin rather than comprehensive.
The server covers the two most essential vision bridge capabilities—image understanding and text extraction. However, other potentially useful operations like object detection or image comparison are absent, leaving minor gaps in the surface.
Maintenance
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
OCR, transcription, file extraction, and image generation for AI agents via MCP.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Free OpenAI-compatible inference with signed provenance receipts and 3 focused MCP tools.
Create images & video from any MCP agent — 17 models, spend limits, one URL.
Related MCP Servers
- AlicenseAqualityCmaintenanceGive MCP-compatible AI agents image analysis, metadata inspection, cropping, OCR, and image comparison through any OpenAI-compatible vision model.6MIT
- AlicenseAqualityBmaintenanceEnables any MCP client to perform image understanding and OCR via any OpenAI-compatible vision-language model. Supports local, private inference without images leaving the machine.211MIT
- AlicenseAqualityCmaintenanceEnables text-only reasoning models to see images by wrapping vision-language models as MCP tools, supporting image description, OCR, chart analysis, and custom questioning within MCP-compatible IDEs.4MIT
- AlicenseAqualityCmaintenanceEnables any MCP-capable agent to perform vision tasks like describing images, answering questions, OCR, and comparing images using supported vision backends.5MIT