Skip to main content
Glama
LZMW

MCP Vision Server

by LZMW
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

MCP Vision Server - 图像识别 MCP 服务器

提供图像分析能力的 MCP 服务器，支持图像识别、文字提取、多轮对话等功能。

特性

  • 图像分析 - 支持各种图像内容识别与描述

  • 多轮对话 - 基于图像的连续问答

  • 灵活输入 - 支持本地文件路径和 Base64 编码

  • OpenAI 兼容 - 使用 OpenAI 兼容 API，支持多种视觉模型

  • 会话持久化 - 对话历史可持久化存储

Related MCP server: Image Parse MCP

安装

# 克隆仓库
git clone https://github.com/YOUR_USERNAME/mcp-vision-server.git
cd mcp-vision-server

# 创建虚拟环境
python -m venv venv
source venv/Scripts/activate  # Windows Git Bash

# 安装依赖
pip install -e .

配置

  1. 复制环境变量模板：

cp .env.example .env

  1. 编辑 .env 文件，填入您的 API 配置：

# 必填配置
VISION_API_KEY=your-api-key-here
VISION_BASE_URL=https://open.bigmodel.cn/api/paas/v4/
VISION_MODEL=glm-4v

使用方法

启动服务器

mcp-vision-server

或直接运行：

python -m mcp_vision.server

Web 配置工具

启动 Web 配置界面，支持热加载配置：

mcp-vision-config

或指定端口：

mcp-vision-config --host 127.0.0.1 --port 8080

访问 http://127.0.0.1:7860 即可打开配置界面。

功能特性：

  • 📝 可视化编辑所有配置项

  • 🔄 保存后自动热加载，无需重启服务

  • 🔒 API Key 密码隐藏显示

  • 📋 实时查看当前运行配置

MCP 工具

1. analyze_image - 图像分析

分析图像内容并返回详细描述。

# 基础用法
analyze_image(
    image="C:/path/to/image.png",
    prompt="详细描述这张图片"
)

# OCR 文字提取
analyze_image(
    image="C:/docs/scan.png",
    prompt="提取图片中的所有文字"
)

# 代码识别
analyze_image(
    image="C:/code/snippet.png",
    prompt="识别并转录图片中的代码，保持格式"
)

2. chat_vision - 两轮对话

基于图像进行两轮问答。

# 第一轮对话
result1 = chat_vision(
    image="C:/chart.png",
    question="这个图表显示什么数据？"
)
session_id = result1["session_id"]
# remaining_turns = 1, can_continue = True

# 第二轮对话（追问细节，对话结束后无法继续）
if result1["remaining_turns"] > 0:
    result2 = chat_vision(
        image="C:/chart.png",
        question="数据有什么趋势？",
        session_id=session_id
    )
    # remaining_turns = 0, can_continue = False

# 开始新对话
result3 = chat_vision(
    image="C:/another.png",
    question="描述这张图",
    is_new_conversation=True
)

3. get_status - 状态查询

获取服务器运行状态。

status = get_status()
# 返回: 服务器名称、模型信息、会话状态等

输入格式

支持两种图像输入格式：

1. 本地文件路径

image="C:/Users/name/Pictures/screenshot.png"
image="/home/user/images/photo.jpg"

2. Base64 编码

# 纯 Base64
image="iVBORw0KGgoAAAANSUhEUgAA..."

# Data URL 格式
image="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..."

环境变量

变量名

说明

默认值

VISION_API_KEY

API 密钥

-

VISION_BASE_URL

API 基础 URL

-

VISION_MODEL

模型名称

glm-4v

VISION_MAX_IMAGE_SIZE

最大图像大小（字节）

20971520 (20MB)

VISION_TIMEOUT

请求超时（秒）

120

VISION_TEMPERATURE

温度参数

0.7

VISION_MAX_TOKENS

最大输出 tokens

4096

VISION_LOG_LEVEL

日志级别

INFO

VISION_MAX_HISTORY

对话历史最大保存数

50

VISION_ENABLE_PERSISTENCE

启用持久化

true

VISION_HISTORY_PATH

历史文件路径

~/.mcp-vision/history.json

支持的图像格式

  • PNG

  • JPEG / JPG

  • GIF

  • WebP

  • BMP

  • TIFF

项目结构

mcp-vision-server/
├── src/mcp_vision/
│   ├── __init__.py           # 包初始化
│   ├── server.py             # MCP 服务器主文件
│   ├── config.py             # 配置管理
│   ├── vision_client.py      # 视觉 API 客户端
│   ├── image_processor.py    # 图像处理
│   ├── chat_manager.py       # 对话管理器
│   ├── web_config.py         # Web 配置工具
│   └── utils.py              # 工具函数
├── tests/
├── .env.example
├── pyproject.toml
└── README.md

在 Claude Code 中配置

编辑 Claude Code 配置文件，添加 MCP 服务器：

{
  "mcpServers": {
    "vision": {
      "command": "mcp-vision-server",
      "env": {
        "VISION_API_KEY": "your-api-key",
        "VISION_BASE_URL": "https://open.bigmodel.cn/api/paas/v4/",
        "VISION_MODEL": "glm-4v"
      }
    }
  }
}

许可证

MIT License

Available Tools

3 tools
analyze_imageA

分析图像内容

这是核心工具，用于分析图像并返回详细描述。

使用场景：

  • 图像内容识别与描述

  • 文字提取（OCR）

  • 代码截图识别

  • 数据图表分析

  • 技术图表理解

参数说明：

  • image: 支持本地文件路径（如 C:/path/to/image.png）或Base64编码

  • prompt: 分析指令，告诉AI你想了解图像的什么内容

示例：

# 基础图像描述
analyze_image(image="C:/screenshots/desktop.png", prompt="描述这张截图的内容")

# OCR文字提取
analyze_image(image="C:/docs/scan.png", prompt="提取图片中的所有文字")

# 代码识别
analyze_image(image="C:/code/snippet.png", prompt="识别并转录图片中的代码")

返回内容：

  • status: 执行状态（"success"或"error"）

  • result: 分析结果

  • image_info: 图像信息（类型、大小等）

ParametersJSON Schema
NameRequiredDescriptionDefault
imageYes图像输入：本地文件路径或Base64编码
promptNo分析指令详细描述这张图片

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.9/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 of behavioral disclosure. It mentions the tool returns detailed descriptions and lists specific use cases, which helps understand its behavior. However, it doesn't disclose important traits like rate limits, authentication requirements, error handling, or whether it's read-only vs. destructive. The description adds some context but leaves significant behavioral 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 is well-structured with clear sections (purpose, usage scenarios, parameter explanation, examples, return content) and every sentence adds value. It's appropriately sized for a tool with 2 parameters and comprehensive examples, with no wasted text 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 has 2 parameters with 100% schema coverage and an output schema (implied by the '返回内容' section), the description provides good contextual completeness. It covers purpose, usage scenarios, parameter semantics with examples, and return values. The main gap is lack of behavioral transparency details that would be important for a tool performing image analysis.

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 description coverage is 100%, so the schema already documents both parameters well. The description adds value by providing concrete examples of parameter usage in different scenarios (basic description, OCR, code recognition) and clarifies that 'image' accepts both local file paths and Base64 encoding, which enhances understanding beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose as '分析图像内容' (analyze image content) and specifies it returns detailed descriptions, which is a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like 'chat_vision' or 'get_status', leaving some ambiguity about when to choose one over another.

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 '使用场景' (usage scenarios) section provides clear contexts for when to use this tool: image content recognition, OCR, code screenshot recognition, data chart analysis, and technical chart understanding. This gives good guidance, but it doesn't explicitly state when NOT to use it or mention alternatives among sibling tools.

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

chat_visionA

两轮对话式图像问答

支持基于图像的两轮对话：

  • 第一轮：根据图像和本地AI的询问信息进行回复

  • 第二轮：如果本地AI对图像画面细节有进一步追问，则回答

使用场景：

  • 深度图像分析

  • 迭代式问题探索

  • 复杂图像理解

参数说明：

  • image: 图像输入（路径或Base64）

  • question: 问题

  • session_id: 会话ID（用于第二轮对话，首次调用可不提供）

  • is_new_conversation: 是否开始新对话（设为true会创建新会话）

两轮对话流程：

  1. 第一轮：调用时不传session_id，AI分析图像并回复，返回会话ID

  2. 第二轮：传入session_id继续追问图像细节，AI回答后对话结束

  3. 超过两轮将无法继续，需开始新对话

示例：

# 第一轮对话
result1 = chat_vision(
    image="C:/chart.png",
    question="这个图表显示什么数据？"
)
session_id = result1["session_id"]

# 第二轮对话（追问细节，对话结束后无法继续）
if result1["remaining_turns"] > 0:
    result2 = chat_vision(
        image="C:/chart.png",
        question="数据有什么趋势？",
        session_id=session_id
    )

返回内容：

  • status: 执行状态

  • answer: 回答

  • session_id: 会话ID

  • conversation_turn: 当前对话轮次（1或2）

  • remaining_turns: 剩余对话轮次

  • can_continue: 是否可以继续对话

ParametersJSON Schema
NameRequiredDescriptionDefault
imageYes图像输入：本地文件路径或Base64编码
questionYes关于图像的问题
session_idNo会话ID（多轮对话用）
is_new_conversationNo是否开始新对话

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does so well by disclosing key behavioral traits: the two-round conversation limit ('超过两轮将无法继续'), session management requirements, and workflow constraints. It also describes the return structure and state tracking (e.g., 'remaining_turns', 'can_continue'), though it could mention potential error conditions or performance characteristics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (使用场景, 参数说明, 两轮对话流程, 示例, 返回内容), but it is verbose with repetitive information (e.g., the workflow is explained in multiple places). Some sentences could be condensed without losing clarity, making it less front-loaded than ideal.

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?

Given the tool's complexity (multi-round conversation with state management), no annotations, and the presence of an output schema, the description is highly complete. It covers purpose, usage, parameters, workflow, examples, and return values, providing sufficient context for an agent to use the tool correctly without relying on structured fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the baseline is 3. The description adds some value by explaining the conversational flow implications of parameters (e.g., 'session_id' for second-round dialogue, 'is_new_conversation' to create new sessions) and providing usage examples, but doesn't significantly enhance semantic understanding beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs 'two-round conversational image Q&A' with specific verbs ('analyze', 'answer') and resources ('image', 'question'), distinguishing it from sibling tools like 'analyze_image' by emphasizing the conversational aspect. However, it doesn't explicitly contrast with 'get_status', leaving some ambiguity in sibling differentiation.

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?

The description provides explicit usage scenarios ('深度图像分析', '迭代式问题探索', '复杂图像理解'), detailed two-round workflow instructions, and clear when-to-use guidance (e.g., '首次调用可不提供' for session_id, '超过两轮将无法继续'). It effectively guides the agent on proper invocation timing and limitations.

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

get_statusB

获取服务器状态

返回当前服务器配置和运行状态信息。

返回内容：

  • server_name: 服务器名称

  • provider: AI服务提供商

  • model: 当前使用的模型

  • chat_manager: 对话管理器状态

  • config: 当前配置信息

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns server status information, implying a read-only operation, but does not explicitly confirm safety (e.g., non-destructive), rate limits, authentication needs, or error handling. The description adds basic context about what information is returned, but lacks depth on behavioral traits beyond the core functionality.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: it starts with the purpose, then details the return content in a structured list. The use of markdown-like formatting (e.g., '---' and bullet points) enhances readability. However, the inclusion of '返回内容' (return content) details might be redundant if an output schema exists (which it does), slightly reducing efficiency.

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 low complexity (0 parameters, simple read operation) and the presence of an output schema (which should cover return values), the description is reasonably complete. It explains the purpose and outlines return fields, which is sufficient for a status-checking tool. However, it lacks behavioral details like error cases or performance considerations, preventing a perfect score.

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 tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description does not need to compensate for any parameter gaps. It appropriately focuses on the output, listing return fields like server_name, provider, model, etc., which adds value beyond the input schema. This meets the baseline for zero parameters, but does not go above by explaining parameter interactions or constraints (since there are none).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: '获取服务器状态' (get server status) and elaborates with '返回当前服务器配置和运行状态信息' (returns current server configuration and running status information). This specifies the verb ('get'/'return') and resource ('server status'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools (analyze_image, chat_vision), which serve entirely different purposes, so it falls short of a perfect score.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools or any contextual cues for selection. The only implied usage is to retrieve server status, but there is no explicit when/when-not advice or prerequisites, leaving the agent to infer usage based solely on the purpose statement.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedanalyze_image
    • First observedchat_vision
    • First observedget_status
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

The three tools have clearly distinct purposes with no overlap: analyze_image for general image analysis, chat_vision for conversational image Q&A, and get_status for server monitoring. Each tool serves a unique function in the vision analysis workflow, making it easy for an agent to select the right one.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (analyze_image, chat_vision, get_status) with clear, descriptive verbs. The naming is uniform and predictable across the entire toolset, making it easy to understand each tool's function at a glance.

Tool Count4/5

Three tools is appropriate for a vision server's core functionality, covering analysis, conversation, and status checking. However, the count feels slightly minimal—additional tools like batch processing or image preprocessing could enhance completeness, but the current set is well-scoped for basic operations.

Completeness4/5

The toolset covers essential vision tasks: analysis, iterative questioning, and server status. Minor gaps exist, such as lacking tools for image manipulation (e.g., resize, crop) or batch processing, but agents can work around these with the provided tools for most common use cases in image understanding.

Maintenance

ActivityInactive
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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LZMW/mcp-vision-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server