This server provides eight vision tools via MCP, using the GLM vision model (glm-5v-turbo) to analyze images and videos for AI coding clients.
UI to Artifact: Convert UI screenshots into frontend code, AI prompts, design specs, or natural language descriptions.
Text Extraction (OCR): Extract text, code (with indentation), terminal output, and documents from screenshots.
Error Diagnosis: Analyze error messages, stack traces, and logs to identify root causes and suggest fixes.
Technical Diagram Understanding: Interpret architecture, flowcharts, UML, ER, and sequence diagrams with structured explanations.
Data Visualization Analysis: Extract trends, anomalies, and business insights from dashboards and charts.
UI Diff Check: Compare two UI screenshots to detect visual differences and implementation deviations.
General Image Analysis: Comprehensive understanding of any visual content not covered by specialized tools.
Video Analysis: Understand scenes, extract key moments, and identify objects/people/activities (supports MP4, MOV, M4V, etc., max 8MB).
Additional features: smart retry with exponential backoff, local LRU caching (optional disk persistence), and wide image/video format support (jpg, png, webp, gif, bmp, tiff, avi, mkv, webm, flv).
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., "@glm-vision-mcp Describe what's happening in this image."
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.
English · 中文
Feature | Description |
8 tools, same names | Identical tool names and parameter schemas as |
Next-gen model by default | Uses glm-5v-turbo — improved accuracy and reasoning over the official glm-4.6v |
Smart retry | 429 / 5xx / network errors retried with exponential backoff; 4xx fails immediately — saves quota |
Local result cache | LRU memory cache + optional disk persistence; same image + prompt skips the API call |
|
|
Extended formats | Images: jpg, png, webp, gif, bmp, tiff. Video: mp4, mov, m4v, avi, mkv, webm, flv |
Related MCP server: glm-vision
# 1. Copy and edit .env
cp .env.example .env
# Set Z_AI_API_KEY=your_coding_plan_key
# 2. Add to your MCP client
claude mcp add glm-vision-mcp \
--env Z_AI_API_KEY=YOUR_KEY \
-- npx -y glm-vision-mcpThe server exposes 8 vision tools through stdio. Your MCP client handles tool discovery and invocation automatically.
claude mcp add glm-vision-mcp \
--env Z_AI_API_KEY=YOUR_KEY \
-- npx -y glm-vision-mcp{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"glm-vision-mcp": {
"type": "local",
"command": ["npx", "-y", "glm-vision-mcp"],
"environment": { "Z_AI_API_KEY": "YOUR_KEY", "Z_AI_MODE": "ZHIPU" }
}
}
}{
"mcpServers": {
"glm-vision-mcp": {
"command": "npx",
"args": ["-y", "glm-vision-mcp"],
"env": { "Z_AI_API_KEY": "YOUR_KEY", "Z_AI_MODE": "ZHIPU" }
}
}
}flowchart LR
Client["MCP Client\n(Claude Code / OpenCode / Cline)"]
Server["glm-vision-mcp\n(stdio transport)"]
Cache["Result Cache\n(LRU + disk)"]
Vision["VisionService\n(unified handler)"]
Chat["ChatService\n(retry + backoff)"]
API["GLM Vision API\n(ZHIPU / ZAI)"]
Client --> Server
Server --> Cache
Cache -->|"miss"| Vision
Cache -->|"hit"| Server
Vision --> Chat
Chat --> API
API --> VisionVariable | Default | Description |
| Required | Zhipu API key (Coding Plan key or pay-as-you-go key) |
| — | Fallback alias (auto-mapped) |
|
| Endpoint mode — see Billing Modes |
|
| Vision model ID |
|
| Sampling temperature |
|
| Nucleus sampling |
|
| Max output tokens |
|
| Request timeout (ms) |
|
| Max retries (retryable errors only) |
|
| Enable result caching |
|
| Cache TTL in seconds (7 days) |
|
| Max LRU cache entries |
|
| Max image file size |
|
| Max video file size |
Choose the endpoint via Z_AI_MODE:
| Endpoint | Billing |
|
| GLM Coding Plan subscription quota |
|
| Pay-as-you-go API billing |
|
| International z.ai platform |
Use the key that matches your billing plan: a Coding Plan key with ZHIPU, or a pay-as-you-go API key with ZHIPU_API.
src/
├── core/ # Environment, chat, vision, file, cache services
│ ├── environment.ts # Dotenv + multi-endpoint + key fallback
│ ├── chat-service.ts # GLM API calls with smart retry
│ ├── vision-service.ts # Unified analysis orchestration
│ ├── file-service.ts # Validation, base64 encoding, fingerprinting
│ └── cache.ts # LRU + disk cache
├── tools/
│ ├── definitions.ts # 8-tool data-driven definitions
│ └── registry.ts # Tool registration on MCP server
├── prompts/ # 8 specialized system prompts
├── types/ # Error type hierarchy
└── utils/ # Logger, sanitization, validation
tests/
scripts/
└── smoke.ts # End-to-end verification with real keyLayer | Technology |
Runtime | Node.js ≥ 18 |
Language | TypeScript 5 |
Protocol |
|
Validation | Zod |
Config | dotenv |
Build | TypeScript compiler ( |
Dev | tsx (hot-reload), vitest (64 tests) |
Fork → branch → commit → open a pull request. Run npm test before pushing.
Released under the MIT License.
阅读仪表盘、统计图表，提炼趋势、异常与业务要点。
仅在用户需要以下操作时使用：
从图表提取洞察
识别趋势与模式
检测异常值
提供业务影响分析
不要用于：技术架构图、UI 截图、错误诊断。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 详细描述要分析/生成的内容 | |
| image_source | Yes | 本地文件路径或图片 URL | |
| analysis_focus | No | 可选：聚焦方面（如 trends/anomalies/comparisons/performance） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly discloses that the tool reads dashboards/charts and extracts trends, anomalies, and business points, which is the core behavior. However, it does not mention the output format or any limitations (e.g., single image, chart clarity), so it is not fully transparent.
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 very concise: a single-sentence purpose statement followed by a bulleted list of use cases and exclusions. Every sentence earns its place, and the structure front-loads the main purpose before giving usage guidance.
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 that there is no output schema, the description does not explain the exact return format, but it does state what the tool produces (trends, anomalies, business points). It covers when to use, when not to use, and the core functionality, making it fairly complete for a single-image analysis tool.
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?
All three parameters have schema descriptions (100% coverage), so the baseline is 3. The description adds value by aligning its four use cases (extract insights, identify trends, detect anomalies, business impact) with the `analysis_focus` parameter's possible values, and it implicitly instructs how to phrase the `prompt` parameter.
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 uses specific verbs (阅读/提炼) and identifies the resource (仪表盘、统计图表), clearly stating it analyzes data visualizations to extract trends, anomalies, and business insights. It also explicitly differentiates from siblings by stating what it is NOT for: technical architecture diagrams, UI screenshots, and error diagnosis.
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 explicitly says '仅在用户需要以下操作时使用' (only use when the user needs the following operations) and lists four concrete use cases. It also provides a '不要用于' (do not use for) list with three exclusions, which clearly guides the agent away from using it on non-data-visualization inputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
通用图像理解能力，适配未被专项工具覆盖的视觉内容。
仅在用户需要以下操作时使用：
当专项工具（UI/OCR/错误/图表/数据可视化/视频）都不适用时
灵活理解任何视觉内容
全面的图像描述和分析
这是兜底工具，优先使用更专业的工具。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 详细描述要分析/生成的内容 | |
| image_source | Yes | 本地文件路径或图片 URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a clear behavioral boundary: it is a fallback for content not covered by specialized tools, and it provides comprehensive description/analysis. However, it does not describe output format, error handling, or any hidden behaviors, leaving a modest gap.
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 compact and well-structured: a clear opening statement, a bulleted list of use cases, and a closing fallback warning. Every line adds meaningful value with 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?
For a simple 2-parameter, no-output-schema tool, the description provides adequate invocation context. It names sibling categories to avoid mis-selection and clarifies the fallback role. It could be slightly more complete by explicitly stating that output is a textual analysis, but overall it is sufficient.
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%, with both parameters adequately described ('image_source' as path/URL, 'prompt' as detailed request). The tool description adds no extra parameter context beyond restating the general purpose, so the baseline 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 a specific function: general image understanding for visual content not covered by specialized tools. It explicitly contrasts with the sibling tool categories (UI/OCR/error/chart/data visualization/video), making it distinct from all seven siblings.
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 explicit when-to-use guidance: '仅在用户需要以下操作时使用' and lists conditions including when specialized tools are not applicable. It also explicitly states '这是兜底工具，优先使用更专业的工具', giving clear exclusions and prioritization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
使用 AI 视觉模型分析视频内容。
仅在用户需要以下操作时使用：
理解视频中发生了什么
提取关键时刻或动作
分析视频内容、场景或序列
识别视频中的对象、人物或活动
支持本地文件与远程 URL，最大 8MB，支持 MP4/MOV/M4V 等格式。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 详细描述要分析/生成的内容 | |
| video_source | Yes | 本地视频文件路径或远程 URL（支持 MP4/MOV/M4V 等） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses important constraints such as max 8MB, supported formats (MP4/MOV/M4V), and local/remote URL support. However, it does not describe the output format, error handling, or any potential side effects, leaving some behavioral ambiguity.
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 concise and well-structured: a one-sentence purpose, a bulleted list of use cases, and a final constraints line. No redundancy or unnecessary details, making it easy to parse quickly.
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 tool with only 2 parameters and no output schema, the description covers purpose, clear usage scenarios, and input constraints. It lacks details about the output format, but the intended use cases are simple enough that an agent can infer the expected result. The description is largely complete for selection and invocation.
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 description coverage is 100%, with both parameters clearly described. The description adds an 8MB size limit and confirms format support, but these are minor additions. The schema already explains the purpose of each parameter, so the description's marginal value is limited.
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: '使用 AI 视觉模型分析视频内容' (use AI vision model to analyze video content). It lists four specific use cases, distinguishing it from sibling tools like analyze_image by explicitly targeting video.
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 explicit usage guidance with '仅在用户需要以下操作时使用' (only use when the user needs) and a bulleted list of scenarios. It doesn't mention alternatives or when-not-to-use cases, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
解析错误弹窗、堆栈跟踪和日志截图，给出定位与修复建议。
仅在用户需要以下操作时使用：
分析错误消息和堆栈跟踪
定位根本原因
提供可操作的修复方案
不要用于：提取代码、UI 分析、图表解读。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 详细描述要分析/生成的内容 | |
| context | No | 可选：发生错误的上下文（如运行环境、触发操作） | |
| image_source | Yes | 本地文件路径或图片 URL |
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 specifies input types (error dialogs, stack traces, logs) and output (localization and fix suggestions), but does not discuss privacy, accuracy limitations, or explicitly state non-mutating behavior beyond the verb '提供建议' implying no side effects. It is adequate but not rich.
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 concise, consisting of three clear sentences. It is front-loaded with the core function, followed by explicit when-to-use and when-not-to-use lists, with no redundant content. Every sentence earns its place.
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, but the description covers purpose, usage boundaries, and explicitly mentions output as localization and fix suggestions. However, it lacks details on return format, failure handling, or limitations. Given the moderate complexity of diagnosing error screenshots, the description is minimally sufficient but not comprehensive.
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 description coverage is 100%, meaning all three parameters (image_source, prompt, context) are already fully documented in the input schema. The description adds no extra parameter-level semantics beyond what the schema provides. Baseline 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 uses specific verbs like '解析' (parse) and '给出建议' (provide suggestions) targeting error dialogs, stack traces, and log screenshots. This clearly distinguishes it from siblings such as extract_text_from_screenshot (generic text extraction) and analyze_data_visualization (charts), making the tool's purpose unambiguous.
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 explicitly states when to use (only when user needs to analyze error messages, locate root causes, or get fix suggestions) and when not to use (do not use for extracting code, UI analysis, or chart interpretation). However, it does not name specific alternative tools, so it falls short of a 5 per the rubric's requirement for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
使用 OCR 从截图中提取和识别文字。专门用于代码、终端输出、文档和通用文本提取。
仅在用户需要以下操作时使用：
从截图提取代码（保持正确缩进与格式）
提取终端输出和日志
提取文档和文本内容
不要用于：UI 转 code、错误诊断、图表分析。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 详细描述要分析/生成的内容 | |
| image_source | Yes | 本地文件路径或图片 URL | |
| programming_language | No | 可选：截图中的编程语言提示，提高准确性 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the burden of behavioral disclosure. It mentions OCR-based extraction and preserves formatting for code, which are useful behaviors. However, it does not disclose potential limitations like OCR accuracy on low-quality images or language support, nor what exactly is returned beyond 'text'. This is acceptable but not fully transparent.
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 concise and well-structured, using a clear opening line followed by bullet points for usage and exclusions. Every sentence contributes either to purpose, usage, or differentiation, with 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?
Given the tool's moderate complexity and absence of an output schema, the description adequately covers what the tool is for, when to use it, and what not to use it for. It implies the output is extracted text, which is sufficient for this simple read-only tool. It could add a note about expected output format, but overall it is 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 schema covers all three parameters with descriptions, so the baseline is 3. The high-level description adds context about intended use cases (code, terminal, docs), which indirectly informs what the 'prompt' should contain, but it doesn't provide any new parameter-specific details beyond the schema. Thus it stays at baseline.
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: using OCR to extract and recognize text from screenshots, specifically for code, terminal output, documents, and general text. It explicitly distinguishes from siblings by listing what not to use it for (UI-to-code, error diagnosis, chart analysis), which maps directly to sibling tools.
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 explicit when-to-use scenarios (extracting code, terminal output, documents) and a clear 'do not use for' list, giving strong guidance relative to alternatives. This goes beyond generic instructions by naming out-of-scope tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
对比两张 UI 截图，识别视觉差异和实现偏差。专门用于 UI 质量保证和设计到实现的验证。
仅在用户需要以下操作时使用：
比较预期 UI 与实际实现
识别视觉差异
提供详细差异报告
按严重程度排列问题优先级
需要两张图：预期/参考图 与 实际/当前图。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 详细描述要分析/生成的内容 | |
| actual_image_source | Yes | 实际/当前 UI 截图路径或 URL | |
| expected_image_source | Yes | 预期/参考 UI 截图路径或 URL |
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 reveals the core behavior (comparing images, identifying differences, producing a report) but does not mention side effects, permissions, supported formats, or limitations. Since the tool is inherently read-only, the lack of side-effect disclosure is a minor gap but not misleading.
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 concise and well-structured: the purpose is front-loaded in the first sentence, followed by a clear bulleted list of use cases and a final note about required inputs. Every sentence earns its place, with no redundancy or filler.
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 or annotations, so the description should clarify the return value. It mentions a 'detailed diff report' with severity prioritization but does not specify the report format or any limitations (e.g., image formats, size limits). Given the tool's relative simplicity, this is adequate but not fully comprehensive.
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%, so the baseline is 3. The description only restates that two images are required (expected vs. actual), which duplicates the schema parameter descriptions. It adds no extra meaning for the 'prompt' parameter beyond what's already provided.
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 compares two UI screenshots to identify visual differences and implementation deviations, and positions it specifically for UI QA and design-to-implementation verification. This distinguishes it from sibling tools like analyze_image or extract_text_from_screenshot, which have different purposes.
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 explicitly lists when to use the tool ('仅在用户需要以下操作时使用') with four concrete use cases, providing clear context. However, it does not name alternative tools or explicitly state when not to use it, so it stops short of full when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
将 UI 截图转换为代码、提示词、设计规范或自然语言描述。
仅在用户需要以下操作时使用：
从 UI 设计生成前端代码（output_type='code'）
创建用于 UI 复刻的 AI 提示词（output_type='prompt'）
提取设计规范文档（output_type='spec'）
获取 UI 的自然语言描述（output_type='description'）
不要用于：需提取的文字/代码、错误信息、技术图表、数据可视化。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 详细描述要分析/生成的内容 | |
| output_type | Yes | 产物类型：'code'(前端代码)/'prompt'(复刻提示词)/'spec'(设计规范)/'description'(自然语言描述) | |
| image_source | Yes | 本地文件路径或图片 URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently defines the tool's scope (UI screenshots only) and output types, and explicitly excludes other use cases. It does not disclose potential failure modes or limitations, but for a transform tool that is acceptable.
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 concise, front-loading the core purpose in the first sentence, then using brief bullet-style lists for when-to-use and when-not-to-use. Every sentence adds value, with no repetition or filler.
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 tool with three required parameters and no output schema, the description fully covers selection criteria and expected artifacts. It explains what the tool produces (code, prompt, spec, description) and explicitly excludes non-UI content, making it complete for an agent to decide invocation.
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 provides 100% coverage for all three parameters. The description enhances this by mapping each output_type enum value to its real-world use (e.g., 'code' for frontend code, 'prompt' for UI reproduction), adding semantic context beyond the schema's simple descriptions.
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 converts UI screenshots into code, prompts, design specs, or natural language descriptions. It uses a specific verb and resource, and distinguishes itself from siblings by listing exclusions like text extraction and technical diagrams.
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 explicitly lists when to use the tool (four specific output_type scenarios) and when not to use it (text/code extraction, error messages, technical diagrams, data visualizations). This provides clear selection criteria versus sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
分析技术图表并生成结构化解读，覆盖架构图、流程图、UML、ER 图、序列图等。
仅在用户需要以下操作时使用：
分析架构图
理解流程图与 UML 图
解释 ER 图与序列图
识别设计模式
不要用于：UI 截图、错误消息、数据可视化图表。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 详细描述要分析/生成的内容 | |
| diagram_type | No | 可选：图表类型（如 architecture/flowchart/uml/er-diagram/sequence） | |
| image_source | Yes | 本地文件路径或图片 URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses scope and exclusions but does not explicitly state read-only nature, expected output format, or error conditions. The phrase 'generate structured interpretation' hints at output but lacks detail.
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 concise, with the main purpose front-loaded and usage guidelines neatly separated. Every sentence earns its place—no filler or 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 has no annotations or output schema, so the description must define context fully. Usage guidelines are strong, but return format and behavioral edge cases are underexplained. Overall adequate but not as complete as it could be for a complex multi-diagram-type tool.
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%, so parameters are already documented. The description reinforces the diagram_type list but adds no new meaning for prompt or image_source. It meets the baseline but does not enrich parameter understanding.
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 technical diagrams and generates structured interpretation, enumerating specific diagram types (architecture, flowchart, UML, ER, sequence). This distinguishes it from siblings like analyze_data_visualization and analyze_image, which handle other image categories.
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?
Explicit 'Only use when' and 'Do not use for' sections provide clear inclusion and exclusion criteria, naming alternatives (UI screenshots, error messages, data visualization) and giving concrete use cases. This is exemplary guidance for an agent deciding between tools.
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.
v0.1.0analyze_data_visualizationanalyze_imageanalyze_videodiagnose_error_screenshotextract_text_from_screenshotui_diff_checkui_to_artifactunderstand_technical_diagramScored across 8 tools
Each tool targets a distinct visual input type (UI, text, error, diagram, data viz, diff, generic, video) with explicit 'do not use for' boundaries. The generic analyze_image is clearly positioned as a fallback, preventing overlap with specialized tools.
All names use snake_case, but verb-first pattern is inconsistent: ui_to_artifact and ui_diff_check are noun-first while others are verb-first. Still, the style is uniform and readable.
8 tools is well-scoped for a vision analysis server, covering major categories of visual understanding without unnecessary bloat.
The tool surface covers UI conversion, OCR, error diagnosis, diagrams, data visualization, diff checking, generic image analysis, and video analysis—a comprehensive set for the domain. The fallback analyze_image ensures no dead ends.
MCP server for GLM chat completions using Zhipu AI models via AceDataCloud
MCP server for Qwen Image 3 AI image generation
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for building and testing AI agents with multi-model experimentation and insights.