depu-img-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., "@depu-img-mcpdescribe this image: https://example.com/cat.png"
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.
depu-img-mcp
图像理解 MCP 服务器 —— 让不支持图像的文本模型通过 MCP 把图片 + prompt 转发给视觉模型,返回描述文本。自身不做推理,是协议适配与转发层。
特性
MCP v2(
MCPServer+ Streamable HTTP,2026-07-28 规范),同时支持 stdio / SSEDocker 部署(多阶段构建 + docker-compose)
多后端 provider:任意 OpenAI 兼容端点(LiteLLM 网关 / vLLM / OpenAI / DashScope / 智谱 / OpenRouter / Ollama …)
双层 prompt 注入:全局
base_vision_prompt+ per-callprompt+task_type路由(auto/general/ocr/ui/debug/describe)安全:magic byte 校验、大小限制、SSRF 防护、路径白名单
轻量 Web 后台(
/admin):查看配置 + 在线测试图片配置双源:环境变量覆盖
config.toml,密钥支持${ENV}插值
Related MCP server: vision-bridge-mcp
快速开始
# 1. 准备 .env(至少填 ADMIN_TOKEN 和视觉后端 API key)
cp .env.example .env
# 编辑 .env 填入 API key
# 2. Docker 启动(首次会自动生成 ./conf/config.toml 默认配置)
docker compose up -d
# 3. 访问后台改配置(或直接编辑 ./conf/config.toml 后重启)
open http://localhost:8080/admin
# MCP 端点:http://localhost:8080/mcp首次启动无需预先准备
config.toml:容器挂载./conf/目录,若里面没有配置文件,会自动从内置模板生成一份。之后可在/admin后台在线编辑,或直接改./conf/config.toml后docker compose restart。
本地运行(开发)
uv sync
uv run python -m depu_img_mcp # 默认 streamable-http
MCP_TRANSPORT=stdio uv run python -m depu_img_mcp # stdio 模式给 Claude Desktop 等MCP 工具
image_understand
image_understand(
image: str, # http(s) URL 或 data:image/...;base64,... URI(内联 base64)。不支持本地文件路径(Docker 部署,容器看不到客户端文件系统)
prompt: str = "", # 用户问题;空则给出通用描述(物体、文字/OCR、布局、颜色等)
) -> strprovider / model 由后台 admin 统一配置,客户端不能指定。这用于企业内网服务,后端路由由运维通过
/admin后台决定。
只有一个工具。客户端传图 + prompt,服务器用后台配置的默认 provider 及其 model 进行视觉理解,返回文本描述。
配置示例
[[providers]]
name = "default"
type = "openai-compat"
base_url = "https://gateway.ai.depu.school/v1"
api_key = "${DEPU_GATEWAY_API_KEY}"
model = "Kimi-K2.7-Code"
auth_header = "bearer"客户端配置(Claude Desktop 示例)
stdio 模式:
{
"mcpServers": {
"depu-img": {
"command": "python",
"args": ["-m", "depu_img_mcp"],
"env": { "MCP_TRANSPORT": "stdio", "DEPU_GATEWAY_API_KEY": "sk-..." }
}
}
}HTTP 模式(支持远程 MCP 的客户端):
{
"mcpServers": {
"depu-img": { "url": "http://localhost:8080/mcp" }
}
}License
MIT
Available Tools
1 toolimage_understandA
Describe or analyze an image using a vision model.
Call this whenever you need to understand an image you cannot see. The backend provider and model are determined by the server admin configuration and cannot be overridden from the client.
Args: image: The image as an http(s) URL, or a data:image/...;base64,... URI (inline base64). Local file paths are NOT supported because the server runs in a container and cannot see the client filesystem — encode the file as a base64 data URI first. prompt: What you want to know about the image. Empty = a general description of the image (objects, text/OCR, layout, colors).
Returns: The vision model's text description of the image.
| 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, the description carries full burden. It discloses that the backend provider/model is fixed by server admin, that local file paths are unsupported due to containerization, and that the return is a text description. These are meaningful behavioral traits beyond the basic operation.
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 clear purpose, then logically organized with usage, args, and returns. Every sentence adds necessary information—even the container explanation is essential for preventing misuse. No 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?
The tool is simple (2 params, no annotations) and the description covers its operation, usage context, parameter details, constraints, and return value. The output schema is also described in text, making the tool's behavior fully specified.
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 schema descriptions are absent (0% coverage). The description compensates thoroughly by explaining that 'image' accepts http(s) URLs or base64 data URIs, explicitly excluding local paths and why, and describing the 'prompt' parameter's default behavior when empty.
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 states 'Describe or analyze an image using a vision model' and adds 'Call this whenever you need to understand an image you cannot see.' This gives a clear verb and resource, making the purpose unambiguous even without sibling comparisons.
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?
It provides direct usage guidance: 'Call this whenever you need to understand an image you cannot see.' It also explains a key limitation (local file paths not supported) and how to work around it, giving practical when-to-use context.
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.
1 tool update
v0.1.0- First observed
image_understand
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion or overlapping purposes.
A single tool name is trivially consistent; there are no conflicting naming conventions to assess.
One tool for image understanding is thin but acceptable for a single-purpose server; it sits at the low end of the typical range.
The tool provides comprehensive image understanding (description, OCR, layout, colors) and accepts both URLs and base64, covering the full domain without obvious gaps.
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.
Create images & video from any MCP agent — 17 models, spend limits, one URL.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables text-only LLMs to analyze images by routing them to an OpenAI-compatible vision backend, supporting local files, URLs, and data URLs.24MIT
- AlicenseAqualityBmaintenanceEnables non-multimodal models to see images by providing MCP tools for image understanding and OCR, backed by any OpenAI-compatible vision model.2MIT
- 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
- AlicenseNot gradedqualityCmaintenanceProvides vision capabilities to text-only LLMs via MCP, enabling image understanding, Q&A, OCR, and image processing through cloud multimodal APIs.MIT