glm-vision-mcp

by JJChou000

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.1.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
8 tools is well-scoped for a vision analysis server, covering major categories of visual understanding without unnecessary bloat.
Completeness5/5
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.
Average 4.2/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 27 commits in the last 12 weeks
- No stable releases found
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/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 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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

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:

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

Score Badge

Copy to your README.md:

[![glm-vision-mcp MCP server](https://glama.ai/mcp/servers/JJChou000/glm-vision-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JJChou000/glm-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/JJChou000/glm-vision-mcp'

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