vision-mcp

by Pelican0126

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
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.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on June 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vision-mcp MCP server](https://glama.ai/mcp/servers/Pelican0126/vision-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Pelican0126/vision-mcp)

Score Badge

Copy to your README.md:

[![vision-mcp MCP server](https://glama.ai/mcp/servers/Pelican0126/vision-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Pelican0126/vision-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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

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

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