Skip to main content
Glama

depu-img-mcp

图像理解 MCP 服务器 —— 让不支持图像的文本模型通过 MCP 把图片 + prompt 转发给视觉模型,返回描述文本。自身不做推理,是协议适配与转发层。

特性

  • MCP v2MCPServer + Streamable HTTP,2026-07-28 规范),同时支持 stdio / SSE

  • Docker 部署(多阶段构建 + docker-compose)

  • 多后端 provider:任意 OpenAI 兼容端点(LiteLLM 网关 / vLLM / OpenAI / DashScope / 智谱 / OpenRouter / Ollama …)

  • 双层 prompt 注入:全局 base_vision_prompt + per-call prompt + 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.tomldocker 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、布局、颜色等)
) -> str

provider / 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 tool
image_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
imageYes
promptNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev0.1.0
    • First observedimage_understand

TDQS

A4.9/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion or overlapping purposes.

Naming Consistency5/5

A single tool name is trivially consistent; there are no conflicting naming conventions to assess.

Tool Count3/5

One tool for image understanding is thin but acceptable for a single-purpose server; it sits at the low end of the typical range.

Completeness5/5

The tool provides comprehensive image understanding (description, OCR, layout, colors) and accepts both URLs and base64, covering the full domain without obvious gaps.

Maintenance

ActivitySlowing
ResponsivenessNo issues

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

Related MCP Servers