What can you do with this server?

The vision-mcp server gives text-only coding agents the ability to "see" and analyze images and videos by routing visual content to a compatible vision model backend and returning structured text results. Core Tools: * ui_to_artifact – Convert UI screenshots or design mockups into runnable code (React, Vue, HTML) or structured specifications. * extract_text_from_screenshot – Verbatim OCR extraction from screenshots, code, terminal output, error messages, and documents. * diagnose_error_screenshot – Analyze error/crash screenshots to identify root cause, verbatim error text, file/line location, and fix steps. * understand_technical_diagram – Interpret architecture diagrams, flowcharts, UML, ER, and sequence diagrams. * analyze_data_visualization – Read charts and dashboards to extract values, trends, anomalies, and insights. * ui_diff_check – Compare two UI screenshots and enumerate visual and implementation differences. * image_analysis – General-purpose fallback for understanding any image and answering arbitrary questions. * video_analysis – Analyze videos (screen recordings, clips); falls back to ffmpeg frame-sampling if the backend lacks native video support. Key Features: * Agentic Auto-Zoom: Automatically zooms coarse→fine from the full-resolution original to read tiny text or details that downsampling would lose. * Flexible detail_level: overview, normal, fine, or auto (zooms only when needed). * Multiple image sources: Local file paths, file://, http(s):// URLs, data: URIs, 'clipboard' (OS clipboard), or 'latest' (newest file in a drop directory). * Structured output: Returns both human-readable markdown and machine-readable metadata (confidence score, zoom regions, processing rounds, model/provider used). * Any OpenAI-compatible backend: Works with GLM, Kimi, OpenAI GPT-4o, local vLLM/Ollama, etc. * Security: Path allowlisting, SSRF checks on URLs, magic-byte file validation, and size caps.

Which integrations are available for this server?

Supports local Ollama vision models via an OpenAI-compatible endpoint, enabling private image and video analysis without sending data to external services. Integrates with OpenAI's vision API to provide image and video analysis capabilities including OCR, UI-to-code generation, error diagnosis, diagram understanding, chart reading, UI diff, and generic image understanding. Integrates with Xiaomi's MiMo vision models (e.g., mimo-v2.5) to perform image and video analysis tasks such as OCR, UI understanding, error diagnosis, and diagram interpretation.

How do I use vision-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vision-mcp diagnose this error screenshot" 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.

vision-mcp

by Pelican0126

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

vision-mcp

Give eyes to any "blind" coding agent — a local MCP server that lets text-only models see screenshots, error images, design mockups and video.
给所有看不见图的编码 agent 装上眼睛 —— 一个本地 MCP 服务，让纯文本模型也能看懂截图、报错图、设计稿和视频。

English · 中文

It hands images to a vision model "out of band" and returns text + machine-readable metadata to the host, so a host that can't see images (GLM coding model, DeepSeek, Qwen-coder, local models…) effectively gains sight. Works with any OpenAI-compatible vision backend (GLM / Kimi / Xiaomi MiMo / OpenAI / local vLLM), and adds server-led agentic zoom to read details that downsampling would otherwise lose.

English

Features

8 task-specific tools: UI→code, OCR, error diagnosis, diagram understanding, chart reading, UI diff, generic image, video.
Any OpenAI-compatible backend via one provider + per-backend profile. Switch with 3 env vars. GLM by default.
Agentic auto-zoom: server crops & upscales coarse→fine (grid → grounding → precise crop) from the full-resolution original, so tiny text becomes legible. Verified to fix hallucination on small detail (see Verified).
Universal video: backends without native video automatically get ffmpeg frame-sampling → multi-image.
Dual output: content (structured markdown) + structuredContent (confidence / regions / rounds / warnings / provider / model).
Safe by default: local-path allowlist, URL download + SSRF check (no blind passthrough), magic-byte validation, size caps.

How it works (30-second mental model)

host tool(image, detail_level)
  → validate + load media (full-res original + downsampled overview; path allowlist; URL SSRF)
  → overview ? single pass : zoomLoop (deterministic grid → model votes/grounding → crop original → early-exit)
  → content(markdown) + structuredContent(metadata)

The vision model is a "consultant" hired for one question; only its text answer comes back to the host. Crops always come from the full-resolution original (never the downsampled overview), so zoom actually recovers detail.

Quick start

1. Install & build (Node ≥ 20)

npm install
npm run build

2. Pick a backend. Default is GLM (z.ai). Any OpenAI-compatible /chat/completions endpoint with image_url support works — set 3 env vars:

export VISION_API_KEY=your_key
export VISION_BASE_URL=https://api.z.ai/api/paas/v4
export VISION_MODEL=glm-4.6v

3. Connect your MCP client (zcode / Cline / Cursor / Claude Desktop …). Add to its mcpServers config:

{
  "mcpServers": {
    "vision": {
      "command": "node",
      "args": ["<ABSOLUTE_PATH>/dist/index.js"],
      "env": {
        "VISION_API_KEY": "your_key",
        "VISION_BASE_URL": "https://api.z.ai/api/paas/v4",
        "VISION_MODEL": "glm-4.6v",
        "VISION_ALLOWED_DIRS": "<ABSOLUTE_PATH_TO_YOUR_PROJECT>"
      }
    }
  }
}

Timeout: reasoning vision models are slow (code/spec generation can take 30–60s+). Set your host's MCP tool timeout generously (≥120s). During deep zoom the server emits notifications/progress, so clients that honor resetTimeoutOnProgress stay alive.

Usage tutorial

The host is a text-only agent — it never sees the image. You tell the agent where the image is (a path under VISION_ALLOWED_DIRS, or a URL / data URI) and which tool to use; the agent calls the tool, the server returns text, the agent continues.

Example 1 — diagnose an error screenshot

Save your screenshot at e.g. ./screenshots/error.png (inside an allowed dir).
Ask your agent: "Use the vision MCP diagnose_error_screenshot on ./screenshots/error.png."
The tool returns markdown sections ## Root cause / ## Verbatim error / ## Location / ## Fix steps, and the agent uses it to write the fix.

Example 2 — read a tiny detail (agentic zoom)

For small text the model can't read at a glance, pass detail_level: "fine":

// the call your agent makes
{ "name": "extract_text_from_screenshot",
  "arguments": { "image": "./screenshots/big.png", "detail_level": "fine",
                 "question": "read the small key code in the bottom-right corner" } }

The server runs the zoom loop: it grids the image, the model votes which region matters, the server crops that region from the original and re-reads it — recovering text that a single overview pass would misread. structuredContent.regions shows where it looked, rounds how many passes it took.

detail_level values: overview (single fast pass) · normal · fine (deep zoom) · auto (default — zooms only when needed, early-exits when clear).

Example 3 — analyze a video

{ "name": "video_analysis",
  "arguments": { "video": "./clips/repro.mp4", "question": "what bug is shown?" } }

If the backend has no native video, the server samples frames with ffmpeg and analyzes them as images — so video works on any vision backend.

Quick local test (no client needed) — the MCP Inspector:

npx @modelcontextprotocol/inspector node dist/index.js
# then set the env vars in the Inspector UI and call any tool

Or run the bundled scripts: node scripts/smoke.mjs (lists tools), KEY=... node scripts/livetest.mjs (drives all 8 tools end-to-end).

Text-only hosts (e.g. ZCode + GLM-5.2): give a path, don't paste

If your host coding model is text-only (GLM-5.2, DeepSeek, …), do not paste/drag an image into the chat — the host attaches it to the model's turn and the provider rejects it (400 Model only support text input). DeepSeek silently drops the image instead (looks fine, but it never saw anything). vision-mcp runs downstream of the host, so it cannot intercept a pasted image.

Instead, let the agent pull the image itself so it never reaches the text model — three ways:

File path (zero setup): save the image and reference its path — "use diagnose_error_screenshot on D:\shots\err.png". The host sees only the text path; the MCP reads the file.
image: "clipboard": screenshot to the clipboard (Win+Shift+S) or copy an image, then say "read the error image on my clipboard". The MCP reads the OS clipboard server-side (built-in PowerShell on Windows — no dependency).
image: "latest": set VISION_DROP_DIR to a screenshots folder; the MCP grabs the newest image there.

Also: the vision backend (VISION_MODEL) must itself be a vision model — a text-only model like glm-5.2 can't be the backend either (use Doubao-vision / GLM-4.6V / a *-vision model).

Why DeepSeek "just works" but GLM-5.2 400s (both are blind): it's the upstream endpoint, not the model. Volcano's GLM-5.2 endpoint strictly rejects any request that contains an image; DeepSeek's endpoint silently ignores it and lets the model proceed to call this MCP. ZCode embeds the pasted image for both and has no per-model "vision" toggle — so there is no ZCode setting that fixes it; you simply avoid pasting and pull the image via the tool instead.

Verified end-to-end (ZCode + GLM-5.2 host + mimo-v2.5 backend): screenshot to clipboard → ask "look at the clipboard image and diagnose" → GLM-5.2 called image_analysis(image="clipboard") → mimo read ERR-4096: NPE app.ts:42 verbatim and counted the chart bars. No 400.

ZCode tips: turn off 计划模式 (Plan mode) when you want it to actually run the tool (in Plan mode it only plans); on the tool-approval prompt choose "始终允许本项目" (Always allow this project) so it stops asking each time.

Tools

Tool	Purpose
`ui_to_artifact`	UI screenshot → code / spec
`extract_text_from_screenshot`	verbatim OCR
`diagnose_error_screenshot`	error diagnosis (root cause / verbatim / location / fix)
`understand_technical_diagram`	architecture / flow / UML / ER / sequence diagrams
`analyze_data_visualization`	read charts / dashboards
`ui_diff_check`	compare two UI screenshots
`image_analysis`	generic image understanding (fallback)
`video_analysis`	video understanding (native or frame-sampled)

Common params: detail_level, question, region, thinking.

Backends

Backend	`VISION_PROFILE`	`VISION_BASE_URL`	`VISION_MODEL`
GLM (z.ai)	`glm`	`https://api.z.ai/api/paas/v4`	`glm-4.6v`
Kimi (Moonshot)	`kimi`	`https://api.moonshot.ai/v1`	`<kimi vision model>`
Xiaomi MiMo	`mimo`	`<your endpoint>/v1`	`mimo-v2.5` (vision build)
OpenAI	`openai`	`https://api.openai.com/v1`	`gpt-4o`
local vLLM/Ollama	`generic`	`http://localhost:8000/v1`	`<local VLM>`

Any OpenAI-compatible endpoint with image_url support works with generic.

Configuration (env)

Var	Default	Notes
`VISION_API_KEY` (alias `Z_AI_API_KEY`)	— required	backend key
`VISION_PROFILE`	`glm`	`glm` / `kimi` / `mimo` / `openai` / `generic`
`VISION_BASE_URL`	per profile	OpenAI-compatible endpoint
`VISION_MODEL`	per profile	vision model id
`VISION_ALLOWED_DIRS`	cwd	dirs allowed for local image paths (`;`/`:` separated)
`VISION_ALLOW_URL_PASSTHROUGH`	`false`	forward image URLs to the backend (default: download + SSRF-check → data URI)
`VISION_MAX_ZOOM_ROUNDS`	`3`	max agentic zoom rounds
`VISION_MAX_EDGE_PX`	`1568`	overview downsample longest edge
`VISION_VIDEO_FRAMES`	`8`	frames sampled per video
`VISION_MAX_IMAGE_MB` / `_VIDEO_MB`	`10` / `50`	size caps

Verified live

Tested against Xiaomi MiMo (mimo-v2.5 vision / mimo-v2.5-pro blind):

All 8 tools work end-to-end.
Agentic zoom proven: a tiny key code in a corner — overview hallucinated it (REV: 2A-74A1-0); detail_level=fine navigated to the bottom-right and read the correct KEY: ZX-7741-Q consistently across re-runs.
Video frame-sampling: mimo has no native video → auto frame-sampling succeeded.
Blind model degrades gracefully: mimo-v2.5-pro returns 404 No endpoints found that support image input → tool returns isError + a clear message, no crash.

Reproduce: KEY=... PROFILE=mimo MODEL=mimo-v2.5 BASE=<endpoint>/v1 node scripts/livetest.mjs.

Privacy

Your images/video are sent to the configured backend API. Don't use untrusted backends for sensitive content; a local deployment (generic profile → local vLLM) keeps data on your machine.

Development

npm run dev    # run source via tsx
npm run build  # tsc → dist/
npm test       # vitest, fully offline (no API key) — 33 tests

Tests cover the zoom state machine (early-exit / budget / parse-fail / out-of-bounds / grounding / tool-calling), media security (magic-bytes / path traversal / SSRF / downscale), tool schemas, and video frame sampling.

Architecture

src/: provider/ (OpenAI-compatible client + profiles), core/zoomLoop.ts, media/ (load / transform / security / video), tools/, prompts.ts.

Related MCP server: Atlas Vision MCP

中文

让纯文本模型也能「看见」：把图交给视觉模型「带外」分析，只把文字结论 + 机器可读元数据回传宿主。支持任何 OpenAI 兼容的视觉后端（GLM / Kimi / 小米 MiMo / OpenAI / 本地 vLLM），并用 server 主导的 agentic 缩放读出降采样会丢失的细节。

特性

8 个任务专用工具：UI 转代码、OCR、报错诊断、技术图理解、图表读数、UI 对比、通用图像、视频理解。
多后端：一个 provider + per-backend profile，改 3 个 env 即切换，GLM 默认。
Agentic 自动缩放：从全分辨率原图由粗到细裁切放大（九宫格 → grounding → 精确裁切），让小字可读；已实测能修正小细节上的幻觉（见已联机验证）。
视频通用：无原生视频能力的后端自动走 ffmpeg 帧采样 → 多图分析。
双输出：content（结构化 markdown）+ structuredContent（confidence / regions / rounds / warnings / provider / model）。
默认安全：本地路径白名单、URL 默认下载 + SSRF 校验（不透传）、magic-bytes 校验、大小上限。

工作原理（30 秒心智模型）

宿主 tool(image, detail_level)
  → 校验 + 载媒体（全分辨率原图 + 降采样概览图；路径白名单；URL SSRF）
  → overview ? 单次 : zoomLoop（确定性网格 → 模型投票/grounding → 裁原图 → 早退）
  → content(markdown) + structuredContent(元数据)

视觉模型是为「一个问题」临时请来的顾问，只有它的文字答案回到宿主。裁切始终从全分辨率原图取（不是降采样图），所以缩放才能真正找回细节。

快速上手

1. 安装构建（Node ≥ 20）

npm install
npm run build

2. 选后端。默认 GLM（z.ai）。任何支持 image_url 的 OpenAI 兼容端点都行，设 3 个 env：

export VISION_API_KEY=你的key
export VISION_BASE_URL=https://api.z.ai/api/paas/v4
export VISION_MODEL=glm-4.6v

3. 接入 MCP 客户端（zcode / Cline / Cursor / Claude Desktop……），在其 mcpServers 配置里加：

{
  "mcpServers": {
    "vision": {
      "command": "node",
      "args": ["<绝对路径>/dist/index.js"],
      "env": {
        "VISION_API_KEY": "你的key",
        "VISION_BASE_URL": "https://api.z.ai/api/paas/v4",
        "VISION_MODEL": "glm-4.6v",
        "VISION_ALLOWED_DIRS": "<你的项目绝对路径>"
      }
    }
  }
}

超时：推理型视觉模型较慢（生成代码/规格可能 30–60s+）。把宿主的 MCP 工具超时设宽松些（≥120s）。深度缩放期间 server 会发 notifications/progress，支持 resetTimeoutOnProgress 的客户端可借此保活。

使用教程

宿主是纯文本 agent，永远看不到图。你告诉它图在哪（VISION_ALLOWED_DIRS 下的路径，或 URL / data URI）、用哪个工具；agent 调用工具，server 回文字，agent 继续干活。

例 1 — 诊断报错截图

把截图存到 ./screenshots/error.png（在允许目录内）。
对 agent 说：「用 vision MCP 的 diagnose_error_screenshot 分析 ./screenshots/error.png」。
工具返回 ## 根因 / ## 错误原文 / ## 位置 / ## 修复步骤，agent 据此写修复。

例 2 — 读小细节（agentic 缩放）

模型一眼读不清的小字，传 detail_level: "fine"：

{ "name": "extract_text_from_screenshot",
  "arguments": { "image": "./screenshots/big.png", "detail_level": "fine",
                 "question": "读出右下角的小密钥码" } }

server 跑缩放循环：把图划网格 → 模型投票哪块相关 → 从原图裁该块重读，找回单次概览会读错的文字。structuredContent.regions 显示它看了哪、rounds 显示用了几轮。

detail_level 取值：overview（单次快速）·normal·fine（深度缩放）·auto（默认，需要才缩放、清晰则早退）。

例 3 — 分析视频

{ "name": "video_analysis",
  "arguments": { "video": "./clips/repro.mp4", "question": "视频里是什么 bug？" } }

后端无原生视频时，server 用 ffmpeg 抽帧当多图分析 —— 任意视觉后端都能处理视频。

本地快测（无需客户端） —— MCP Inspector：

npx @modelcontextprotocol/inspector node dist/index.js
# 在 Inspector 界面里填好 env，点任意工具

或用自带脚本：node scripts/smoke.mjs（列工具）、KEY=... node scripts/livetest.mjs（全 8 工具端到端）。

文本宿主（如 ZCode + GLM-5.2）：给路径，别粘贴

如果你的宿主编码模型是纯文本（GLM-5.2、DeepSeek……），别把图粘贴/拖进对话——宿主会把图塞进模型的 turn，提供商直接拒绝（400 Model only support text input）；DeepSeek 则静默丢图（看着没报错，其实没看见）。vision-mcp 在宿主下游，拦不住已粘贴的图。

正确做法：让 agent 自己把图取过来，图永不进文本模型——三条路：

文件路径（零配置）：把图存成文件、给路径——「用 diagnose_error_screenshot 看 D:\shots\err.png」。宿主只见文字路径，MCP 读文件。
image: "clipboard"：截图到剪贴板（Win+Shift+S）或复制一张图，然后说「看剪贴板里的报错图」。MCP 在 server 端读系统剪贴板（Windows 用内置 PowerShell，零依赖）。
image: "latest"：把 VISION_DROP_DIR 设成截图目录，MCP 取里面最新的图。

另外：视觉后端（VISION_MODEL）本身也必须是视觉模型——纯文本模型（如 glm-5.2）不能当后端（用 Doubao-vision / GLM-4.6V / 带 -vision 的模型）。

为什么 DeepSeek"能用"而 GLM-5.2 报 400（两个都是瞎子）： 区别在上游端点，不在模型。火山的 GLM-5.2 端点严格拒绝任何带图的请求；DeepSeek 端点则静默忽略、让模型继续去调本 MCP。ZCode 对两者都会嵌入粘贴的图、且没有按模型的"视觉"开关——所以 ZCode 里没有任何设置能修这个，你只能不粘贴、改用工具把图取过来。

已端到端验证（ZCode + GLM-5.2 宿主 + mimo-v2.5 后端）：截图到剪贴板 → 说*"看剪贴板里的图、诊断报错"* → GLM-5.2 调用 image_analysis(image="clipboard") → mimo 逐字读出 ERR-4096: NPE app.ts:42 并数对柱子。全程不再 400。

ZCode 小贴士： 想让它真正执行工具时，关掉计划模式（计划模式下只会"计划"不执行）；工具授权弹框里选**"始终允许本项目"**，就不用每次确认。

工具

工具	用途
`ui_to_artifact`	UI 截图 → 代码 / 规格
`extract_text_from_screenshot`	逐字 OCR
`diagnose_error_screenshot`	报错诊断（根因/原文/位置/修复）
`understand_technical_diagram`	架构/流程/UML/ER/时序图
`analyze_data_visualization`	图表/仪表盘读数
`ui_diff_check`	两张 UI 截图对比
`image_analysis`	通用图像理解（兜底）
`video_analysis`	视频理解（原生或帧采样）

公共参数：detail_level、question、region、thinking。

后端

后端	`VISION_PROFILE`	`VISION_BASE_URL`	`VISION_MODEL`
GLM (z.ai)	`glm`	`https://api.z.ai/api/paas/v4`	`glm-4.6v`
Kimi (Moonshot)	`kimi`	`https://api.moonshot.ai/v1`	`<kimi 视觉模型>`
小米 MiMo	`mimo`	`<你的端点>/v1`	`mimo-v2.5`（视觉版）
OpenAI	`openai`	`https://api.openai.com/v1`	`gpt-4o`
本地 vLLM/Ollama	`generic`	`http://localhost:8000/v1`	`<本地 VLM>`

任何 OpenAI 兼容、支持 image_url 的端点都能用 generic 直接接入。

配置（env）

变量	默认	说明
`VISION_API_KEY`（别名 `Z_AI_API_KEY`）	— 必填	后端 key
`VISION_PROFILE`	`glm`	`glm` / `kimi` / `mimo` / `openai` / `generic`
`VISION_BASE_URL`	随 profile	OpenAI 兼容端点
`VISION_MODEL`	随 profile	视觉模型
`VISION_ALLOWED_DIRS`	当前目录	允许读取本地图片的目录（`;`/`:` 分隔）
`VISION_ALLOW_URL_PASSTHROUGH`	`false`	是否把图片 URL 直接透传给后端（默认下载+SSRF 校验后转 data URI）
`VISION_MAX_ZOOM_ROUNDS`	`3`	agentic 缩放最大轮数
`VISION_MAX_EDGE_PX`	`1568`	概览图降采样最大边长
`VISION_VIDEO_FRAMES`	`8`	每个视频抽帧数
`VISION_MAX_IMAGE_MB` / `_VIDEO_MB`	`10` / `50`	大小上限

已联机验证

针对 小米 MiMo（mimo-v2.5 视觉版 / mimo-v2.5-pro 盲版）实测：

8 个工具全部端到端跑通。
Agentic 缩放验证有效：角落小密钥码，overview 单次会编造（REV: 2A-74A1-0）；detail_level=fine 导航到右下、复跑稳定读出正确的 KEY: ZX-7741-Q。
视频帧采样：mimo 无原生视频 → 自动抽帧成功。
盲模型优雅降级：mimo-v2.5-pro 返回 404 No endpoints found that support image input → 工具以 isError + 清晰提示返回，不崩溃。

复现：KEY=... PROFILE=mimo MODEL=mimo-v2.5 BASE=<端点>/v1 node scripts/livetest.mjs。

隐私

调用时图片/视频会发送到所配置的视觉后端 API。敏感内容请勿用不可信后端；本地部署（generic → 本地 vLLM）可避免数据外发。

开发

npm run dev    # tsx 直接跑源码
npm run build  # tsc → dist/
npm test       # vitest 离线测试（无需 key）—— 33 个用例

测试覆盖：缩放状态机（早退/预算/解析失败/越界/grounding/tool-calling）、媒体安全（magic-bytes/路径越界/SSRF/降采样）、工具 schema、视频帧采样。

架构

src/：provider/（OpenAI 兼容 + profile）、core/zoomLoop.ts、media/（load/transform/security/video）、tools/、prompts.ts。

Available Tools

8 tools

analyze_data_visualization图表读数A

读懂图表/仪表盘并抽取数据与洞察（趋势、异常、数值）。需要从图表里读出数字或结论时使用。

ParametersJSON Schema

Name	Required	Description
`image`	Yes	图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）
`region`	No	可选：手动指定关注区域，命名如 'top-right' 或归一化 bbox 'x,y,w,h'（0~1）
`question`	No	具体问题或额外要求
`thinking`	No	是否开启视觉模型深度推理（默认按工具/后端策略）
`detail_level`	No	细节级别：overview=单次快速；normal/fine/auto 触发由粗到细的自动缩放（auto 为默认，足够清晰则早退）

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`rounds`	Yes	实际经历的视觉调用轮数
`regions`	No	缩放走过的区域轨迹（归一化 bbox）
`markdown`	Yes	人类可读的结构化 markdown 正文（与 content 一致）
`provider`	Yes
`warnings`	Yes	降级/截断/不确定等告警
`confidence`	No	模型对结果的置信度

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided; description carries full burden. Only states what it does (extract data/insights) but does not disclose behavioral traits like read-only nature, image format support, or behavior when input is not a chart.

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?

Two sentences, no wasted words. Front-loaded with action verb and resource. Every sentence adds value.

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 output schema exists and parameter descriptions are complete, description adequately covers purpose and usage context. Still lacks behavioral transparency, but that is captured separately.

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?

Schema coverage is 100% with detailed parameter descriptions (image sources, region format, etc.). Description adds no additional parameter semantics beyond overall purpose, meeting baseline for high-coverage schema.

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?

Description clearly states the tool reads charts/dashboards and extracts data and insights (trends, anomalies, values). It distinguishes from siblings like understand_technical_diagram and image_analysis by focusing specifically on data visualization outputs.

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?

Explicitly says to use when needing to read numbers or conclusions from charts. Provides clear context but lacks explicit when-not or alternative tool guidance.

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

diagnose_error_screenshot报错截图诊断A

分析报错/异常截图，给出根因、逐字错误原文、位置和可执行的修复步骤。处理崩溃/红屏/堆栈截图时使用。

ParametersJSON Schema

Name	Required	Description
`image`	Yes	图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）
`region`	No	可选：手动指定关注区域，命名如 'top-right' 或归一化 bbox 'x,y,w,h'（0~1）
`question`	No	具体问题或额外要求
`thinking`	No	是否开启视觉模型深度推理（默认按工具/后端策略）
`code_context`	No	相关代码/上下文，帮助定位
`detail_level`	No	细节级别：overview=单次快速；normal/fine/auto 触发由粗到细的自动缩放（auto 为默认，足够清晰则早退）

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`rounds`	Yes	实际经历的视觉调用轮数
`regions`	No	缩放走过的区域轨迹（归一化 bbox）
`markdown`	Yes	人类可读的结构化 markdown 正文（与 content 一致）
`provider`	Yes
`warnings`	Yes	降级/截断/不确定等告警
`confidence`	No	模型对结果的置信度

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the tool's outputs (root cause, verbatim text, location, fix steps) but does not discuss edge cases (e.g., non-error images), required permissions, rate limits, or behavior details. The parameter descriptions add some behavioral info (e.g., vision model deep reasoning via 'thinking'), but the main description is moderately transparent.

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 exceptionally concise: two sentences, front-loaded with purpose and output, followed by usage context. Every word 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.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (6 parameters, output schema exists), the description is fairly complete. It clearly states core function and usage context. It could mention multi-source image support (from parameter description), but the output schema likely covers return structure. Overall, it provides sufficient information for an agent to correctly invoke the tool.

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?

Schema description coverage is 100%, so baseline is 3. The main description does not add parameter-specific detail beyond the schema, but the schema descriptions are already thorough (e.g., image input options, region format, detail levels). The description adds no further meaning, so a 3 is appropriate.

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 clearly specifies the tool's purpose: analyze error/exception screenshots and provide root cause, verbatim error text, location, and actionable fix steps. It also explicitly states when to use it ('处理崩溃/红屏/堆栈截图时使用'), distinguishing it from sibling tools like image_analysis (generic) or extract_text (text extraction only).

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 description includes explicit context for when to use the tool ('crash/red screen/stack screenshots'), which helps the agent select it appropriately. However, it does not provide explicit when-not-to-use guidance or name alternative tools, though the sibling context makes the distinction clear.

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

extract_text_from_screenshot截图 OCRA

逐字提取截图中的文本（代码、终端、报错、文档等），保留阅读顺序与布局。需要把图里的文字读出来时使用。

ParametersJSON Schema

Name	Required	Description
`image`	Yes	图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）
`region`	No	可选：手动指定关注区域，命名如 'top-right' 或归一化 bbox 'x,y,w,h'（0~1）
`question`	No	具体问题或额外要求
`thinking`	No	是否开启视觉模型深度推理（默认按工具/后端策略）
`lang_hint`	No	语言/区域提示，如 'zh'、'代码'
`detail_level`	No	细节级别：overview=单次快速；normal/fine/auto 触发由粗到细的自动缩放（auto 为默认，足够清晰则早退）

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`rounds`	Yes	实际经历的视觉调用轮数
`regions`	No	缩放走过的区域轨迹（归一化 bbox）
`markdown`	Yes	人类可读的结构化 markdown 正文（与 content 一致）
`provider`	Yes
`warnings`	Yes	降级/截断/不确定等告警
`confidence`	No	模型对结果的置信度

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It discloses character-level extraction and preservation of reading order/layout, but lacks details on limitations (e.g., handwriting, font types) or how it handles different image qualities. Adequate but not deeply transparent.

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?

Two sentences, front-loaded with key action. Efficient and to the point. Slight improvement could be adding structured examples or explicit scope, but no extraneous content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters and an output schema, the description gives minimal high-level context. It doesn't discuss region, question, thinking, lang_hint, or detail_level behavior. Schema fills gaps but description could be more complete for agent understanding.

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?

Schema coverage is 100%, so baseline is 3. The description does not add parameter details beyond what the schema provides, but the schema itself is descriptive. The description's value lies in overall context, not per-parameter enhancement.

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 clearly states that the tool extracts text from screenshots character by word, preserving reading order and layout. It specifies supported content types (code, terminal, errors, documents), making the purpose specific and distinct from general image analysis siblings.

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 description provides a clear when-to-use instruction: 'Use when you need to read text from the image.' It implies not to use for non-text image analysis, though it does not explicitly exclude alternatives or name sibling comparisons.

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

image_analysis通用图像理解A

通用兜底：理解任意图片并回答问题。不确定用哪个专用工具，或只是想问一张图时使用。

ParametersJSON Schema

Name	Required	Description
`image`	Yes	图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）
`region`	No	可选：手动指定关注区域，命名如 'top-right' 或归一化 bbox 'x,y,w,h'（0~1）
`question`	No	具体问题或额外要求
`thinking`	No	是否开启视觉模型深度推理（默认按工具/后端策略）
`detail_level`	No	细节级别：overview=单次快速；normal/fine/auto 触发由粗到细的自动缩放（auto 为默认，足够清晰则早退）

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`rounds`	Yes	实际经历的视觉调用轮数
`regions`	No	缩放走过的区域轨迹（归一化 bbox）
`markdown`	Yes	人类可读的结构化 markdown 正文（与 content 一致）
`provider`	Yes
`warnings`	Yes	降级/截断/不确定等告警
`confidence`	No	模型对结果的置信度

TDQS

A3.7/5.0

Behavior2/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 disclosing behavioral traits. However, the description only states a high-level purpose without detailing safety, limitations, privacy considerations, or what happens with different image types. This lack of behavioral context is inadequate for a general-purpose tool.

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 concise at two sentences and front-loaded with the core purpose. It is efficient but could be slightly more structured with a brief list of capabilities or examples. No waste, but room for minor improvement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters and a complex sibling set, the description is minimal. It lacks information about output format, error handling, or expected behavior. While the output schema exists, the description should provide a high-level summary of what the tool returns and how to interpret results, which is missing.

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 input schema has 100% description coverage for all 5 parameters, so the schema already documents parameter meanings clearly. The description adds no additional semantic value beyond the schema. With full 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.

Purpose5/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 a general fallback for understanding arbitrary images and answering questions. It explicitly distinguishes from specialized siblings by advising use when unsure which specialized tool to use, making the purpose and scope very clear.

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 guidance on when to use this tool ('when unsure which specialized tool, or just want to ask about an image'), which implies when not to use it. This directly helps the agent select the appropriate tool among siblings with specialized functions.

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

ui_diff_checkUI 截图对比A

对比两张 UI 截图（A 基准 / B 对照），逐条列出视觉与实现差异及可能的回归。做视觉回归/前后对比时使用。

ParametersJSON Schema

Name	Required	Description
`focus`	No	重点关注的区域/方面
`region`	No	可选：手动指定关注区域，命名如 'top-right' 或归一化 bbox 'x,y,w,h'（0~1）
`image_a`	Yes	基准图 A：路径/URL/data URI
`image_b`	Yes	对照图 B：路径/URL/data URI
`question`	No	具体问题或额外要求
`thinking`	No	是否开启视觉模型深度推理（默认按工具/后端策略）
`detail_level`	No	细节级别：overview=单次快速；normal/fine/auto 触发由粗到细的自动缩放（auto 为默认，足够清晰则早退）

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`rounds`	Yes	实际经历的视觉调用轮数
`regions`	No	缩放走过的区域轨迹（归一化 bbox）
`markdown`	Yes	人类可读的结构化 markdown 正文（与 content 一致）
`provider`	Yes
`warnings`	Yes	降级/截断/不确定等告警
`confidence`	No	模型对结果的置信度

TDQS

A3.6/5.0

Behavior2/5

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 that the tool '逐条列出视觉与实现差异及可能的回归' (lists differences and regressions) but omits any details about how images are processed, stored, or whether the operation has side effects. This lack of transparency is a significant gap.

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 a single, focused sentence that conveys the core purpose and usage context. It is concise and front-loaded, but could potentially include a bit more detail without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters, a required pair, and an output schema, the description is minimal. It relies heavily on the schema for parameter details but does not elaborate on output format or typical scenarios. This is adequate but not thorough.

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?

With 100% schema description coverage, the schema already documents all 7 parameters. The description does not add any additional meaning or context beyond what the schema provides, so 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.

Purpose5/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: comparing two UI screenshots to list visual differences and possible regressions. The title 'UI 截图对比' and the phrase '做视觉回归/前后对比时使用' explicitly indicate its use for visual regression or before/after comparison. This distinctively separates it from sibling tools like image_analysis or diagnose_error_screenshot.

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 description provides clear context by stating '做视觉回归/前后对比时使用' (use for visual regression/before-after comparison). However, it does not explicitly mention when not to use the tool or suggest specific alternatives, leaving some room for interpretation.

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

ui_to_artifactUI 截图转代码/规格A

把一张 UI 截图/设计稿转成可运行代码或结构化规格。当宿主拿到界面图、需要据此生成或还原前端实现时使用。

ParametersJSON Schema

Name	Required	Description
`image`	Yes	图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）
`region`	No	可选：手动指定关注区域，命名如 'top-right' 或归一化 bbox 'x,y,w,h'（0~1）
`target`	No	产出 code（默认）或 spec
`question`	No	具体问题或额外要求
`thinking`	No	是否开启视觉模型深度推理（默认按工具/后端策略）
`framework`	No	目标框架，如 react/vue/html
`detail_level`	No	细节级别：overview=单次快速；normal/fine/auto 触发由粗到细的自动缩放（auto 为默认，足够清晰则早退）

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`rounds`	Yes	实际经历的视觉调用轮数
`regions`	No	缩放走过的区域轨迹（归一化 bbox）
`markdown`	Yes	人类可读的结构化 markdown 正文（与 content 一致）
`provider`	Yes
`warnings`	Yes	降级/截断/不确定等告警
`confidence`	No	模型对结果的置信度

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must fully convey behavioral traits. It only states the conversion action without disclosing any side effects, authentication needs, rate limits, or other behavioral details beyond the input schema. This is insufficient for a tool with 7 parameters.

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 a single sentence that is direct and efficient. Every word earns its place, and it is appropriately front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and 7 parameters, the description is too brief. It does not explain how to combine parameters, what the output format is (though schema exists), or any advanced usage. A more complete description would aid understanding.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal meaning beyond the schema (e.g., 'convert' is implicit in the target parameter). It does not compensate with additional parameter context.

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 clearly states the verb 'Convert' and the resource 'UI screenshot/design draft into runnable code or structured specifications'. It is specific and distinguishes from sibling tools like 'image_analysis' or 'diagnose_error_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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'When the host has a UI image and needs to generate or restore frontend implementation', providing clear when-to-use context. However, it does not mention when not to use or offer alternatives, slightly reducing the score.

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

understand_technical_diagram技术图理解B

解读架构图/流程图/UML/ER/时序图等：节点、连线、流程与设计意图。需要读懂一张技术示意图时使用。

ParametersJSON Schema

Name	Required	Description
`image`	Yes	图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）
`region`	No	可选：手动指定关注区域，命名如 'top-right' 或归一化 bbox 'x,y,w,h'（0~1）
`question`	No	具体问题或额外要求
`thinking`	No	是否开启视觉模型深度推理（默认按工具/后端策略）
`detail_level`	No	细节级别：overview=单次快速；normal/fine/auto 触发由粗到细的自动缩放（auto 为默认，足够清晰则早退）

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`rounds`	Yes	实际经历的视觉调用轮数
`regions`	No	缩放走过的区域轨迹（归一化 bbox）
`markdown`	Yes	人类可读的结构化 markdown 正文（与 content 一致）
`provider`	Yes
`warnings`	Yes	降级/截断/不确定等告警
`confidence`	No	模型对结果的置信度

TDQS

B3.1/5.0

Behavior2/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. It only states 'interpret' without detailing behaviors (e.g., whether it generates text or structured output, how it handles unclear diagrams, or any limitations). The output schema exists but is not referenced in the description.

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 a single sentence, concise and front-loaded with key information. However, it could be slightly longer to include more context without becoming verbose. Every word earns its place, but the brevity limits completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, a required image, and an output schema, the description is insufficient. It omits details about supported image formats, return types, or how it differs from similar image analysis tools. The description is too minimal for an agent to fully understand the tool's capabilities.

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?

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only summarizes the tool's purpose. It does not explain parameter usage or constraints beyond what the schema already provides.

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: interpreting technical diagrams (architecture, flowchart, UML, ER, sequence diagrams). It specifies the resource ('technical diagram') and verb ('interpret'). While it doesn't explicitly differentiate from siblings, the list of diagram types provides enough context to distinguish from general image analysis or error-specific tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage ('Use when you need to read a technical diagram') but offers no explicit guidance on when not to use it or alternatives. No exclusion criteria or comparisons to sibling tools are provided, leaving the agent to infer context.

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

video_analysis视频理解A

理解一段视频（时序+画面）并回答问题。无原生视频能力的后端会自动走帧采样。需要分析录屏/短视频时使用。

ParametersJSON Schema

Name	Required	Description
`video`	Yes	视频：本地路径 / file:// / http(s):// / data: URI
`region`	No	可选：手动指定关注区域，命名如 'top-right' 或归一化 bbox 'x,y,w,h'（0~1）
`question`	No	具体问题或额外要求
`thinking`	No	是否开启视觉模型深度推理（默认按工具/后端策略）
`detail_level`	No	细节级别：overview=单次快速；normal/fine/auto 触发由粗到细的自动缩放（auto 为默认，足够清晰则早退）

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`rounds`	Yes	实际经历的视觉调用轮数
`regions`	No	缩放走过的区域轨迹（归一化 bbox）
`markdown`	Yes	人类可读的结构化 markdown 正文（与 content 一致）
`provider`	Yes
`warnings`	Yes	降级/截断/不确定等告警
`confidence`	No	模型对结果的置信度

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the critical behavior that backends without native video capability will automatically use frame sampling. This transparency helps the agent understand a potential fallback. No mention of destructive effects or auth needs, but the tool is essentially read-only.

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 exceptionally concise with two sentences. The first sentence states the core purpose, and the second adds important behavioral and usage context. Every word is meaningful with no 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 that an output schema exists (not shown but referenced), the description need not cover return values. It covers main functionality, fallback behavior, and usage context. It could mention question scope or limitations, but for a video tool with sibling tools that are image-focused, it is sufficiently complete.

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?

Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only provides general usage context without elaborating on parameters like question formatting or detail_level behavior. Baseline score is appropriate.

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 clearly states the tool understands video (timeline + frames) and answers questions, with a specific use case of screen recordings or short videos. It distinguishes from sibling image tools by focusing on video and mentioning automatic frame sampling for backends without native video capability.

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 description gives clear context by specifying when to use the tool ('analyze screen recordings or short videos'), which implies alternatives for static images. However, it does not explicitly state when not to use it or name alternative tools.

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.

6 tool updatesv0.2.0Jun 25, 2026

Changedanalyze_data_visualization1 field changed

changedInput schema / properties / image / description

Previous value: -"图片：本地路径 / file:// / http(s):// / data: URI"New value: +"图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）"

Changeddiagnose_error_screenshot1 field changed

changedInput schema / properties / image / description

Previous value: -"图片：本地路径 / file:// / http(s):// / data: URI"New value: +"图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）"

Changedextract_text_from_screenshot1 field changed

changedInput schema / properties / image / description

Previous value: -"图片：本地路径 / file:// / http(s):// / data: URI"New value: +"图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）"

Changedimage_analysis1 field changed

changedInput schema / properties / image / description

Previous value: -"图片：本地路径 / file:// / http(s):// / data: URI"New value: +"图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）"

Changedui_to_artifact1 field changed

changedInput schema / properties / image / description

Previous value: -"图片：本地路径 / file:// / http(s):// / data: URI"New value: +"图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）"

Changedunderstand_technical_diagram1 field changed

changedInput schema / properties / image / description

Previous value: -"图片：本地路径 / file:// / http(s):// / data: URI"New value: +"图片：本地路径 / file:// / http(s):// / data: URI / 'clipboard'（读系统剪贴板，文本宿主推荐）/ 'latest'（VISION_DROP_DIR 里最新图）"

8 tool updatesv0.1.0Jun 23, 2026
- First observedanalyze_data_visualization
- First observeddiagnose_error_screenshot
- First observedextract_text_from_screenshot
- First observedimage_analysis
- First observedui_diff_check
- First observedui_to_artifact
- First observedunderstand_technical_diagram
- First observedvideo_analysis

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-06-25 08:50 across 8 tools

Disambiguation5/5

Each tool targets a distinct visual analysis task (charts, errors, text extraction, general, UI diff, UI to code, diagrams, video), with clear usage guidance and a fallback for ambiguity, making selection straightforward.

Naming Consistency3/5

Tool names are in snake_case but mix verb-first (e.g., analyze_data_visualization) and noun-first (e.g., image_analysis, video_analysis) patterns, plus unconventional names like ui_diff_check and ui_to_artifact, creating inconsistency.

Tool Count5/5

With 8 specialized tools, the server is well-scoped for visual analysis, covering diverse needs without being excessive or sparse.

Completeness5/5

The tool set covers major visual understanding scenarios (charts, errors, text, UI, diagrams, video) comprehensively, with only a general fallback for edge cases, leaving no obvious gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Frenchie A
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72
mcp A
io.github.pictify-io
Generate images, GIFs, and PDFs from HTML, URLs, or templates — from your AI agent.
Image & Video Processing Multimedia Processing
262
SnapOG OG Image Generator
com.snapog
Give agents instant OG image generation, social metadata audits, and rendering guidance.
Image & Video Processing Marketing Social Media
2
Vynix A
in.vynix
Give AI coding agents access to your Vynix visual feedback, bug reports, and AI diagnosis.
Testing & QA Tools Monitoring Developer Tools
17114

Related MCP Servers

Vision MCP Server
Image & Video Processing AI & Machine Learning
Loveacup
A
license
A
quality
D
maintenance
Enables AI agents to analyze images, extract text, compare images, and analyze video through any OpenAI-compatible vision model.
Updated 7 months ago (2026-02-09 08:40 UTC)
4
166 npm
20
MIT
Atlas Vision MCP
Image & Video Processing AI & Machine Learning
QuangThai
A
license
A
quality
A
maintenance
Enables text-only coding agents to analyze local images using a dedicated vision provider, returning markdown and structured JSON evidence for screenshots, diagrams, UI mockups, and error captures.
Updated a month ago (2026-08-17 09:07 UTC)
11
21 npm
10
MIT
visual-understand-mcp
Image & Video Processing AI & Machine Learning
bcdxc
F
license
A
quality
D
maintenance
Provides image understanding capabilities to coding models without vision support by automatically invoking a vision model and returning text descriptions, enabling seamless context-aware coding with images.
Updated 3 months ago (2026-06-25 01:27 UTC)
1
2
-
llm-vision-mcp
Image & Video Processing AI & Machine Learning Developer Tools
KuaaMU
A
license
A
quality
A
maintenance
Gives text-only LLM coding agents vision by routing images to a multimodal model and returning detailed textual descriptions. Supports local files, URLs, clipboard, base64, raw bytes, and multiple providers like OpenAI, Anthropic, and Gemini.
Updated a month ago (2026-08-08 13:09 UTC)
1
124 npm
12
MIT