This server enhances text-based LLMs (e.g., DeepSeek, GLM) with visual understanding by processing local image files through OpenAI-compatible vision models via MCP stdio. It can be used through CLI or MCP clients like Claude Code, Opencode, and Kimi Code. Core capabilities:
analyze_image: General-purpose analysis with optional custom prompt.
extract_text: Optical Character Recognition (OCR) to extract text.
describe_ui: Describe user interface screenshots.
diagnose_error: Diagnose error screenshots and suggest fixes.
understand_diagram: Interpret flowcharts, architecture diagrams, etc.
analyze_chart: Extract insights and trends from data charts.
code_from_screenshot: Extract and reconstruct source code from screenshots.
Allows the MCP server to use a local Ollama vision model as the image analysis backend, enabling text-only LLMs to describe images through Ollama's OpenAI-compatible API.
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., "@llm-vision-mcp Describe the image at /home/user/screenshot.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.
通过 MCP stdio 协议为文本模型提供图片理解能力的本地服务，专注磁盘图片分析：
支持任意 OpenAI 兼容的视觉模型供应商（默认 ModelScope 免费的通义千问VL，国内直连，每天 2000 次调用，单模型 500 次），可通过 BASE_URL / VISION_MODEL 切换
通过 MCP stdio 协议供 Claude Code / Opencode 等客户端调用
本地进程运行，不开放任何网络端口
为什么需要？ DeepSeek / GLM 等文本模型的 API 没有视觉能力——给它一个图片路径，它只能"看到"路径本身。本 MCP Server 把图片转成文字描述，让文本模型也能"看图说话"。
Related MCP server: qwen-vision-mcp
已发布到 npm，无需克隆仓库，客户端会通过 npx / pnpm dlx 自动下载运行：
首次使用：获取免费 API Key（默认 ModelScope 供应商，每天 2000 次调用）
打开 https://modelscope.cn 注册/登录
右上角头像 → 个人中心 → 访问令牌（或直接访问 https://modelscope.cn/my/myaccesstoken）
首次使用需绑定阿里云账号（必须，按页面引导完成）
点击"新建访问令牌" → 命名 → 生成 → 复制
令牌格式为
ms-xxxxxxxxxxxx，保留ms-前缀原样作为API_KEY使用
# 验证可用性（启动 stdio MCP Server，Ctrl+C 退出）
npx -y @me9rez/llm-vision-mcp mcp
# 或 pnpm
pnpm dlx @me9rez/llm-vision-mcp mcp然后按下方「客户端配置」把 MCP Server 接入 Claude Code / Opencode / Kimi Code，在 env 中注入 API_KEY 即可；也可以直接用 CLI 分析图片（见「CLI 使用」）。
git clone <仓库地址> && cd llm-vision-mcp
npm install
npm start # 启动 MCP Server
npm test # 单元测试
npm run smoke # 冒烟测试（无需 API Key）不接 MCP 客户端时，也可以在终端直接分析图片：
# 查看帮助（列出全部命令与环境变量）
npx -y @me9rez/llm-vision-mcp --help
# 分析图片（默认通用分析提示词）
npx -y @me9rez/llm-vision-mcp analyze_image ./图片.png
# 带自定义问题
npx -y @me9rez/llm-vision-mcp analyze_image ./图片.png "描述图片中的颜色和字体"
# 其他命令：extract_text（OCR）、describe_ui、diagnose_error、
# understand_diagram、analyze_chart、code_from_screenshot
# 下划线可替换为短横线（如 extract-text），效果相同
# 启动 MCP Server（stdio 模式）
npx -y @me9rez/llm-vision-mcp mcpAPI_KEY=你的密钥 npx -y @me9rez/llm-vision-mcp analyze_image ./图片.png工具 | 功能 |
| 分析磁盘图片文件（可传自定义 |
| 磁盘图片 OCR 提取文字 |
| 分析磁盘 UI 图片 |
| 诊断磁盘错误图片 |
| 解读流程图/架构图 |
| 分析数据图表 |
| 从磁盘图片提取代码 |
Claude Code（.claude/settings.json）：
{
"mcpServers": {
"llm-vision-mcp": {
"command": "npx",
"args": ["-y", "@me9rez/llm-vision-mcp", "mcp"],
"env": {
"API_KEY": "你的_API_Key"
}
}
}
}⚠️ Windows 下如
npx无法直接启动，可将command改为npx.cmd，或使用"command": "cmd", "args": ["/c", "npx", "-y", "@me9rez/llm-vision-mcp", "mcp"]。 完整示例见examples/claude_code_settings.json。
只启用部分工具（减少 agent 上下文占用）→ 见「工具白名单（TOOLS）」。
Opencode（%APPDATA%\opencode\opencode.json）：
{
"mcp": {
"llm-vision-mcp": {
"type": "local",
"command": ["npx", "-y", "@me9rez/llm-vision-mcp", "mcp"],
"enabled": true,
"environment": {
"API_KEY": "你的_API_Key"
}
}
}
}完整示例见
examples/opencode.json。
Kimi Code（~/.kimi-code/mcp.json 用户级，或项目级 .kimi-code/mcp.json；同名条目项目级优先）：
{
"mcpServers": {
"llm-vision-mcp": {
"command": "npx",
"args": ["-y", "@me9rez/llm-vision-mcp", "mcp"],
"env": {
"API_KEY": "你的_API_Key"
}
}
}
}在 TUI 中运行
/mcp查看连接状态；/mcp-config可交互式增删改 server。接入后工具名为mcp__llm-vision-mcp__analyze_image格式，权限规则可用mcp__llm-vision-mcp__*通配。 想限制 Kimi Code 可用的工具，除了本项目的TOOLS/--tools（见「工具白名单」），还可以用 Kimi 原生的enabledTools白名单：在 server 条目中加"enabledTools": ["analyze_image", "extract_text"]。
默认情况下 MCP Server 会注册全部 7 个工具，每个工具的定义（名称、参数、说明）都会占用 agent 的上下文 tokens。只启用你实际需要的工具能让上下文更小，模型响应更快、更省成本。
只影响 MCP 模式；CLI 模式直接指定命令，不受
TOOLS影响。
--tools 启动参数优先级高于 TOOLS 环境变量，两者同时设置时以 --tools 为准。
方式一：TOOLS 环境变量
{
"mcpServers": {
"llm-vision-mcp": {
"command": "npx",
"args": ["-y", "@me9rez/llm-vision-mcp", "mcp"],
"env": {
"API_KEY": "你的_API_Key",
"TOOLS": "analyze_image,extract_text"
}
}
}
}方式二：--tools 启动参数
{
"mcpServers": {
"llm-vision-mcp": {
"command": "npx",
"args": ["-y", "@me9rez/llm-vision-mcp", "mcp", "--tools", "analyze_image,extract_text"],
"env": {
"API_KEY": "你的_API_Key"
}
}
}
}逗号分隔多个工具名，如 analyze_image,extract_text,describe_ui
snake_case 与 kebab-case 均可，以下写法等价：extract_text ≡ extract-text
未知工具名被忽略并打印警告（不影响其他工具）：TOOLS=analyze_image,foo 只会启用 analyze_image，同时输出 [llm-vision-mcp] 忽略未知工具: foo
留空或不设置 = 启用全部工具
# 只做通用分析 + OCR（最常见）
TOOLS=extract_text,analyze_image
# UI 相关三件套
TOOLS=describe_ui,diagnose_error,code_from_screenshot
# 图表 / 架构分析
TOOLS=understand_diagram,analyze_chart启动 MCP Server 后，在客户端执行 tools/list 即可核对：只启用 2 个工具时，列表里只会出现 analyze_image 和 extract_text。完整工具清单见「MCP 工具列表」。
支持任意 OpenAI 兼容的视觉模型供应商，全部通过环境变量配置：
变量 | 必填 | 默认值 | 说明 |
| 是 | - | 供应商密钥（ModelScope 令牌保留 |
| 否 |
| OpenAI 兼容接口地址，可替换为任意供应商 |
| 否 |
| 视觉模型名（如 |
| 否 |
| 采样温度（数字，如 |
| 否 |
| 最大生成长度（正整数） |
| 否 | （全部） | 工具白名单，逗号分隔（如 |
配置其他供应商示例（如本地 Ollama / vLLM 部署）：
{
"mcpServers": {
"llm-vision-mcp": {
"command": "npx",
"args": ["-y", "@me9rez/llm-vision-mcp", "mcp"],
"env": {
"API_KEY": "sk-xxx",
"BASE_URL": "http://localhost:8000/v1",
"VISION_MODEL": "qwen2.5-vl-7b",
"TEMPERATURE": "0.2",
"MAX_TOKENS": "8192"
}
}
}
}本地 stdio 进程运行，不开放任何网络端口
仅接受图片格式（.png .jpg .jpeg .gif .webp .bmp），防止 LLM 注入后读取任意文件
文件大小限制 20MB，扩展名 + 魔数双重校验
图片经 base64 编码发送至视觉模型供应商 API，参阅其隐私政策
deepseek-eyes（MIT）— 本项目参考的原始项目：MCP Server + 通义千问VL，原项目为 Python 实现并含剪贴板工具；本项目以 Node.js 重写并移除了剪贴板工具
视觉模型：通义千问VL / Qwen-VL via ModelScope
MIT — 详见 LICENSE
分析数据图表中的趋势和洞察 / Analyze a chart image file
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | 图片文件的绝对路径 / Absolute path to the image file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions analyzing trends and insights, but does not describe the return format, limitations, or any operational details such as file accessibility requirements.
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 a single bilingual phrase that concisely conveys the core purpose. It is front-loaded, direct, and contains no filler, earning maximum efficiency.
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?
For a one-parameter tool, the description provides the essential purpose but omits expected output format, potential error cases, or differentiation from similar tools like understand_diagram. It is minimally viable but lacks richer context.
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 already fully describes the sole parameter image_path with an absolute path. The tool description adds no further parameter semantics, so it meets the baseline for high schema coverage.
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 analyzes chart images for trends and insights, using a specific verb ('analyze') and resource ('chart image'). While it is specific to charts and thus distinguishable from siblings like analyze_image, it does not explicitly name alternatives for differentiation.
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?
No guidance is provided on when to use this tool versus alternatives. The description simply states what it does, with no mention of conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分析磁盘上的图片文件 / Analyze an image file on disk
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | 自定义问题 | |
| image_path | Yes | 图片路径 |
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 only states that the tool analyzes an image file on disk, but doesn't mention whether it's read-only, what it returns, or any side effects. This is insufficient for an agent to predict the tool's 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?
The description is extremely concise and front-loaded, conveying the core purpose in a single phrase. However, it includes redundant bilingual text (same meaning in Chinese and English), which is minor bloat. Still, it's structured and free of unnecessary words.
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?
There is no output schema, no annotations, and the description is too terse to complete the picture. It doesn't explain what the output looks like, how prompt affects behavior, or any limitations. For a tool with 2 params and simple purpose, this is still inadequate.
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 covers 100% of parameters with descriptions (image_path and prompt). The tool description itself adds no additional parameter semantics, but the baseline of 3 applies since the schema provides adequate information.
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 states a specific action ('analyze') and resource ('image file on disk'), but 'analyze' is vague and doesn't differentiate from sibling tools like extract_text, describe_ui, or analyze_chart. It lacks a clear definition of what kind of analysis is performed.
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?
No usage guidance is provided. The description doesn't indicate when to use this tool versus alternatives, nor does it mention any prerequisites or edge cases. Users are left to infer the tool's role from its name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从磁盘图片中提取代码 / Extract code from a screenshot file
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | 图片文件的绝对路径 / Absolute path to the image file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It only says 'extract code' and gives no details about what the tool returns, whether the file is modified, limitations, or behavior on non-code images.
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 exceptionally concise and front-loaded, with every word contributing to the meaning. The bilingual phrasing is efficient and does not add unnecessary length.
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 has no output schema or annotations, yet the description does not explain what the output looks like or how it handles edge cases. Given the sibling 'extract_text', more context about usage boundaries and return format is needed to fully guide an agent.
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 covers the single parameter with a clear description, and schema description coverage is 100%. The tool description does not add extra meaning beyond the schema, but the baseline of 3 is appropriate when the schema does the heavy lifting.
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 identifies the verb (extract), resource (screenshot file), and what is produced (code). This distinguishes it from generic image analysis tools and even from 'extract_text', since the focus is specifically on code 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?
There is no explicit guidance on when to use this tool versus siblings like 'extract_text' or 'analyze_image'. The description only implies its use for screenshots containing code, but offers no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
描述磁盘上 UI 图片文件 / Describe a UI screenshot file
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | 图片文件的绝对路径 / Absolute path to the image file. |
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 explaining behavior. It only says 'describe a UI screenshot file', which implies a read-only operation but does not explicitly disclose that it is read-only, nor does it mention output format, error handling, or any side effects. The addition of 'on disk' is a minor behavioral detail, but overall it lacks sufficient 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 extremely concise, consisting of only one short bilingual sentence. It is front-loaded with the verb 'describe' and the resource, and every word contributes to the purpose without any unnecessary fluff.
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, but with no output schema and no annotations, the description should do more to explain the return value or behavior. It does not differentiate from sibling tools that might also handle images, and it omits any indication of what the description looks like (e.g., language, detail level). This makes it incomplete for an agent to confidently invoke.
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 description fully covers the single parameter 'image_path' with an absolute path explanation. The tool description adds no further meaning about the parameter, so with high schema coverage, a baseline score of 3 is appropriate.
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 with a specific verb ('describe') and resource ('UI screenshot file'), and mentions 'on disk' to indicate local file access. It is distinct from siblings like extract_text or diagnose_error, but does not explicitly contrast with analyze_image, so it falls short of a 5.
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 implies usage by specifying a UI screenshot file, but provides no explicit guidance on when to use this tool over alternatives like analyze_image or understand_diagram. There are no exclusions or alternative mentions, making the usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
诊断磁盘上错误图片文件 / Diagnose an error screenshot file
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | 图片文件的绝对路径 / Absolute path to the image file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'diagnose' without explaining whether the tool is read-only, what it returns, whether it accesses the file system for any side effects, or any prerequisites. This is a significant gap for a tool that presumably analyzes an image.
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 exceptionally concise, consisting of two short phrases (Chinese and English) that immediately convey the tool's purpose. Every word earns its place, and there is no redundant information.
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 has no output schema and no annotations, yet the description gives no hint about what a 'diagnosis' returns or what capabilities/limitations the tool has. The bilingual phrasing also introduces ambiguity (error image vs. screenshot), leaving the agent under-informed for a tool that could vary widely in behavior.
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 100% for the single parameter 'image_path', whose description already provides the absolute-path requirement. The tool description adds no parameter-specific nuance, so the baseline score of 3 applies.
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 a specific verb ('diagnose') and resource ('error screenshot file'), distinguishing it from sibling tools like analyze_image, extract_text, and describe_ui. The Chinese text reinforces this by specifying '错误图片文件' (error image file), though it slightly differs from the English 'screenshot'.
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 implies use for error screenshot files, providing clear context for when to invoke it. However, it does not explicitly name alternatives or state when not to use it, missing an opportunity to differentiate from the sibling image-analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
从磁盘图片中提取文字(OCR) / OCR an image file on disk
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | 图片文件的绝对路径 / Absolute path to the image file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It identifies the operation as extraction (read-only) but does not mention the output format, potential limitations, or whether the original file is modified. This is a significant gap for a tool with no output schema.
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 a single bilingual sentence, front-loaded with the purpose, and contains no extraneous information. It is extremely concise while conveying the essential function.
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 (one parameter, no output schema), the description should explain the return value or result of the OCR operation, but it does not. It also lacks details about supported image formats or error conditions, making it incomplete for a tool without schema-based output documentation.
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 already provides full coverage (100%) for the single parameter image_path, including its type and description. The tool description adds no additional semantic detail beyond what the schema provides, so the baseline score of 3 is appropriate.
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 performs OCR to extract text from an image file on disk, using a specific verb ('extract'/'OCR') and resource ('text from image file'). It distinguishes itself from sibling tools like analyze_image or describe_ui by naming the exact function.
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 implies the tool is for extracting text via OCR but provides no explicit guidance on when to choose it over alternatives, nor any exclusions. The usage context is inferred from the name and description rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
解读流程图/架构图等图表 / Interpret a diagram image file
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | 图片文件的绝对路径 / Absolute path to the image file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the basic action and resource type, but does not mention output format, limitations, or what 'interpret' entails (e.g., does it return a summary, a JSON structure, or something else?). This leaves significant ambiguity for the agent.
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 a single, front-loaded sentence with no unnecessary words. It is concise and bilingual, with no fluff or repetition of schema information.
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 (one well-documented parameter) and lack of annotations or output schema, the description still feels incomplete because it does not explain what the agent should expect as a result, any prerequisites, or edge cases. The description is too minimal to fully guide the agent.
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 already describes image_path as 'Absolute path to the image file.' The tool description adds value by specifying that the image should be a diagram (flowchart/architecture), giving context about what kind of image is expected. This goes beyond the schema description, so a score above baseline is warranted.
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 function with a specific verb 'interpret' and a specific resource 'diagram image file'. It names diagram types (flowcharts, architecture diagrams) which distinguishes it from sibling tools like analyze_image (general images) and analyze_chart (charts).
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?
Usage context is implied: use this when you have a diagram to interpret. However, there is no explicit guidance on when to use this instead of sibling tools like analyze_image or extract_text, and no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analyze_chartanalyze_imagecode_from_screenshotdescribe_uidiagnose_errorextract_textunderstand_diagramScored across 7 tools
Most tools have clearly distinct purposes (OCR, UI description, error diagnosis, diagram interpretation, chart analysis, code extraction), but 'analyze_image' is a generic catch-all that could overlap with any of the specialized tools, creating potential misselection.
All tool names follow a consistent verb_noun pattern (analyze_image, extract_text, describe_ui, diagnose_error, understand_diagram, analyze_chart), with only 'code_from_screenshot' being a slight deviation but still fitting the overall style.
7 tools is a well-scoped count for a vision analysis server, covering common image tasks without unnecessary bloat or thinness.
The tool set covers general analysis, OCR, UI, errors, diagrams, charts, and code extraction, which is comprehensive for typical vision workflows. Minor gaps like image transformation or object detection exist but are not core to the server's implied purpose.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
MCP server for Qwen Image 3 AI image generation
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Image processing over MCP: compress and split images, generate images and QR codes.
