Which integrations are available for this server?

Supports using Ollama's local vision models as a custom endpoint via VISION_BASE_URL for image analysis and visual reasoning tasks. Provides integration with OpenAI's vision-capable models (e.g., gpt-4o) for image understanding, including image description, text extraction, chart analysis, and visual question answering.

How do I use GLM Vision MCP?

1. Click on "Install 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., "@GLM Vision MCP Extract text from this 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.

GLM Vision MCP

by xiayuyang750

Overview Schema Related Servers Score Discussions

Python

Remote

GLM Vision MCP

How It Works

┌─────────────────────────────────────────────────────────┐
│                    Your IDE / Agent                     │
│                                                         │
│  Text-only model (e.g. DeepSeek-R1)                      │
│       │                                                 │
│       │  "What's in this screenshot?"                    │
│       ▼                                                 │
│  MCP Tool: see_image(path, question)                    │
│       │                                                 │
│       ▼  (stdio / MCP protocol)                         │
│  ┌──────────────────────────────────────────────────┐   │
│  │           GLM Vision MCP Server                  │   │
│  │                                                  │   │
│  │  Reads image → base64 → sends to vision model   │   │
│  │  (GLM-4.6V-Flash / GPT-4o / any VLM)            │   │
│  │                                                  │   │
│  │  Returns: "A login error dialog showing..."      │   │
│  └──────────────────────────────────────────────────┘   │
│       │                                                 │
│       ▼                                                 │
│  Text-only model continues reasoning with vision data   │
└─────────────────────────────────────────────────────────┘

You configure 3 things: model provider, model ID, and API key. The server handles everything else — image reading, base64 encoding, API calls, error handling.

Related MCP server: vision-mcp

Quick Start

1. Install

# From PyPI (once published) or from source:
pip install -e .

Or use directly with uv / pipx without installing:

# Using uv (recommended for MCP)
uv run glm-vision-mcp

2. Configure

The server reads configuration from environment variables:

Variable	Required	Default	Description
`VISION_API_KEY`	✅ Yes	—	Your model provider's API key
`VISION_MODEL_ID`	✅ Yes	`glm-4.6v-flash`	The vision model to use
`VISION_MODEL_PROVIDER`	✅ Yes	`zhipu`	Provider name (see table below)
`VISION_BASE_URL`	❌ No	provider default	Custom API base URL
`VISION_MAX_TOKENS`	❌ No	`2048`	Max response tokens
`VISION_TEMPERATURE`	❌ No	`0.4`	Sampling temperature

3. Add to Your IDE

Cursor

Add to ~/.cursor/mcp.json (or .cursor/mcp.json in your project):

{
  "mcpServers": {
    "glm-vision": {
      "command": "python",
      "args": ["-m", "glm_vision_mcp"],
      "env": {
        "VISION_MODEL_PROVIDER": "zhipu",
        "VISION_MODEL_ID": "glm-4.6v-flash",
        "VISION_API_KEY": "your-zhipu-api-key-here"
      }
    }
  }
}

Trae CN

Add to Trae's MCP settings (设置 → MCP):

{
  "mcpServers": {
    "glm-vision": {
      "command": "python",
      "args": ["-m", "glm_vision_mcp"],
      "env": {
        "VISION_MODEL_PROVIDER": "zhipu",
        "VISION_MODEL_ID": "glm-4.6v-flash",
        "VISION_API_KEY": "your-zhipu-api-key-here"
      }
    }
  }
}

Cline (VS Code)

Add to ~/.cline/mcp_settings.json:

{
  "mcpServers": {
    "glm-vision": {
      "command": "python",
      "args": ["-m", "glm_vision_mcp"],
      "env": {
        "VISION_MODEL_PROVIDER": "zhipu",
        "VISION_MODEL_ID": "glm-4.6v-flash",
        "VISION_API_KEY": "your-zhipu-api-key-here"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

Claude Desktop

Add to claude_desktop_config.json:

{
  "mcpServers": {
    "glm-vision": {
      "command": "python",
      "args": ["-m", "glm_vision_mcp"],
      "env": {
        "VISION_MODEL_PROVIDER": "zhipu",
        "VISION_MODEL_ID": "glm-4.6v-flash",
        "VISION_API_KEY": "your-zhipu-api-key-here"
      }
    }
  }
}

Generic MCP Client (any MCP-compatible tool)

{
  "mcpServers": {
    "glm-vision": {
      "command": "python",
      "args": ["-m", "glm_vision_mcp"],
      "env": {
        "VISION_MODEL_PROVIDER": "zhipu",
        "VISION_MODEL_ID": "glm-4.6v-flash",
        "VISION_API_KEY": "your-api-key"
      }
    }
  }
}

Tip: If you installed via uv, use "command": "uv" and "args": ["run", "glm-vision-mcp"] instead.

Supported Providers

Provider	`VISION_MODEL_PROVIDER`	Default Base URL	Example Models
Zhipu (智谱)	`zhipu`	`https://open.bigmodel.cn/api/paas/v4`	`glm-4.6v-flash`, `glm-4v-plus`
OpenAI	`openai`	`https://api.openai.com/v1`	`gpt-4o`, `gpt-4o-mini`
DeepSeek	`deepseek`	`https://api.deepseek.com/v1`	`deepseek-vl`
Moonshot (Kimi)	`moonshot`	`https://api.moonshot.cn/v1`	`moonshot-v1-8k-vision`
SiliconFlow	`siliconflow`	`https://api.siliconflow.cn/v1`	`Qwen/Qwen2-VL-72B`
Custom	`custom`	(you set `VISION_BASE_URL`)	Any OpenAI-compatible VLM

Using a Custom Endpoint

Set VISION_BASE_URL to point to your own server (vLLM, Ollama, LM Studio, etc.):

{
  "env": {
    "VISION_MODEL_PROVIDER": "custom",
    "VISION_MODEL_ID": "your-model-name",
    "VISION_API_KEY": "any-or-empty",
    "VISION_BASE_URL": "http://localhost:8000/v1"
  }
}

Tools

The server exposes 4 tools. Your IDE's agent will automatically call them when it needs vision:

`see_image` — Core Vision Tool

Ask any question about an image.

see_image(image, question="What is in this image?")

image: File path, URL, or base64 string
question: What you want to know (default: "What is in this image?")

`describe_image` — Image Description

Generate a text description/caption.

describe_image(image, detail_level="detailed")

detail_level: "brief" | "detailed" | "exhaustive" (default: "detailed")

`extract_text` — OCR

Extract all visible text from an image.

extract_text(image, language_hint="Chinese")

language_hint: Optional — e.g. "Chinese", "English", "mixed"

`analyze_chart` — Chart & Diagram Analysis

Analyze charts, graphs, architecture diagrams, or UI screenshots.

analyze_chart(image, question="")

question: Optional specific question (default: general analysis)

Usage Example

Once configured, just talk to your IDE's agent normally:

You: "Look at the screenshot at /tmp/error.png — what's wrong?"

The agent will:

Call see_image("/tmp/error.png", "What error is shown?")
The MCP server sends the image to GLM-4.6V-Flash
GLM returns: "The dialog shows a 'Connection Refused' error..."
Your text-only model uses that answer to help you

Getting an API Key

Zhipu (智谱) — Free Tier Available

Visit https://open.bigmodel.cn
Sign up / log in
Go to API Keys → Create new key
Copy the key (format: xxxxxxxx.xxxxxxxx)

GLM-4.6V-Flash offers free quota — great for testing!

OpenAI

Visit https://platform.openai.com/api-keys
Create a new key

Development

Project Structure

glm-vision-mcp/
├── src/glm_vision_mcp/
│   ├── __init__.py
│   ├── __main__.py          # python -m glm_vision_mcp
│   ├── server.py            # MCP server + tool definitions
│   ├── config.py            # Env-var config loader
│   ├── utils.py             # Image encoding utilities
│   └── providers/
│       ├── base.py          # VisionProvider (shared HTTP logic)
│       ├── zhipu.py         # Zhipu GLM provider
│       ├── openai_compat.py # Generic OpenAI-compatible provider
│       └── registry.py      # Provider name → class mapping
├── examples/
│   └── quickstart.py
├── pyproject.toml
├── requirements.txt
└── README.md

Running Tests

pip install -e ".[dev]"
pytest

Adding a New Provider

Create src/glm_vision_mcp/providers/my_provider.py:

from glm_vision_mcp.providers.base import VisionProvider

class MyProvider(VisionProvider):
    def _build_headers(self):
        # Custom auth if needed
        return {"X-Api-Key": self.config.api_key}

_PROVIDERS["my_provider"] = MyProvider

FAQ

Q: Can I use this with a non-vision model? No — the configured model must support vision input (images). If you're unsure, GLM-4.6V-Flash is a good free option.

Q: Does it work with local images? Yes. Pass a file path and the server will read and base64-encode it automatically.

Q: How fast is it? Depends on the model provider. GLM-4.6V-Flash is very fast (typically 1-3 seconds per image).

Q: Can multiple images be analyzed at once? Currently each tool call handles one image. For multi-image comparison, call see_image multiple times or extend the tools.

License

Available Tools

4 tools

analyze_chartA

Analyze a chart, graph, diagram, or UI screenshot.

Specialised for understanding data visualisations, technical diagrams, flowcharts, and UI screenshots where spatial layout and relationships matter.

Args: image: The chart/diagram image (file path, URL, or base64). question: Optional specific question about the chart. If empty, a general analysis is performed.

Returns: A text analysis of the chart or diagram.

Examples: >>> analyze_chart("/tmp/q1_revenue.png") >>> analyze_chart("/tmp/architecture.png", "What are the main components?")

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes
`question`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

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 that the question is optional and that an empty question triggers general analysis, and it clearly states it returns 'a text analysis'. It also gives examples that clarify expected behavior. It does not mention limitations such as unsupported image formats, but it covers the core behavioral traits transparently.

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 well-structured with 'Args', 'Returns', and 'Examples' sections. It is front-loaded with the core purpose, and every sentence contributes useful information without redundancy. It is appropriately sized for the tool's complexity.

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 two parameters (one optional) and an output schema, the description is comprehensive. It covers purpose, parameter semantics, return type, and provides concrete examples. The output schema already exists, so the description need not detail return values, and it still gives a concise overview.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has zero description coverage, so the description must fully explain parameters. It does so effectively: image is described as 'file path, URL, or base64', and question is explained as optional with behavior defined when 'empty'. This adds significant meaning beyond the raw schema definitions.

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 opens with 'Analyze a chart, graph, diagram, or UI screenshot', using a specific verb and resource. It further distinguishes itself from siblings by specializing in 'data visualisations, technical diagrams, flowcharts, and UI screenshots where spatial layout and relationships matter', clearly differentiating it from see_image and describe_image.

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 strong context for appropriate use, stating it is 'Specialised for understanding data visualisations, technical diagrams, flowcharts, and UI screenshots'. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of full explicit guidance.

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

describe_imageA

Generate a text description of an image.

Useful when you need a caption, alt text, or a general summary of what an image contains without asking a specific question.

Args: image: The image to describe (file path, URL, or base64). detail_level: How detailed the description should be. Options: "brief", "detailed", "exhaustive". Default: "detailed".

Returns: A text description of the image.

Examples: >>> describe_image("/tmp/product.jpg") >>> describe_image("https://site.com/scene.png", "brief")

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes
`detail_level`	No		detailed

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the return format ('Returns: A text description of the image') and the action itself, but does not mention any limitations, potential errors, or processing behavior beyond that. It is adequate for a simple read-only tool but lacks richer behavioral context.

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 well-structured with Args, Returns, and Examples sections. It is concise (about 10 lines), every line adds value, and examples illustrate usage clearly. No redundant or filler content.

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?

Given the tool's simplicity (2 params, no annotations) and the presence of an output schema (though not shown), the description covers all needed aspects: purpose, when to use, parameter semantics, return value, and examples. It is complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description fully compensates. It explains image's format ('file path, URL, or base64') and detail_level's options and default ('brief', 'detailed', 'exhaustive'). This adds significant meaning beyond the bare schema property definitions.

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 action ('Generate a text description of an image') and its purpose (caption, alt text, general summary). It differentiates from sibling tools by emphasizing 'without asking a specific question,' which distinguishes it from more query-specific tools like analyze_chart or extract_text.

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 when-to-use guidance: 'Useful when you need a caption, alt text, or a general summary.' It also implies when-not-to-use by saying 'without asking a specific question,' but it does not explicitly name alternative tools as in the high-calibration example.

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

extract_textA

Extract (OCR) all visible text from an image.

Ideal for screenshots of documents, code, error messages, or any image where the text content matters more than the visual appearance.

Args: image: The image containing text (file path, URL, or base64). language_hint: Optional hint about the text language (e.g. "Chinese", "English", "mixed"). Helps the model focus on the right character set.

Returns: All text found in the image, preserving layout where possible.

Examples: >>> extract_text("/tmp/error_screenshot.png") >>> extract_text("/tmp/receipt.jpg", "Chinese")

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes
`language_hint`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations present, the description carries the full burden of behavioral transparency. It discloses that the tool extracts 'all visible text' and preserves layout 'where possible,' and explains how the language_hint behaves. It does not discuss failure modes, but for a non-destructive OCR tool this is adequate.

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 well-structured with clear sections for usage, arguments, returns, and examples. It is slightly verbose but every sentence provides useful information, earning a strong score without being overly terse.

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 two simple parameters and an output schema present, the description is complete. It covers purpose, ideal use cases, parameter semantics, return format, and provides examples. No critical information is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the 'Args' section fully compensates. It explains that 'image' can be a file path, URL, or base64, and that 'language_hint' is optional with concrete examples. This adds significant semantic meaning beyond the raw 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?

The description clearly states 'Extract (OCR) all visible text from an image,' which is a specific verb and resource. It distinguishes itself from sibling tools like describe_image and analyze_chart by focusing on text extraction rather than visual appearance.

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 identifies ideal use cases: 'screenshots of documents, code, error messages, or any image where the text content matters more than the visual appearance.' This provides clear guidance on when to use the tool, though it does not explicitly state when not to use it.

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

see_imageA

Look at an image and answer a question about it.

This is the core vision tool. Use it whenever you need to understand, describe, or reason about visual content that you cannot see.

Args: image: The image to analyze. Accepts: - A local file path (e.g. /home/user/photo.jpg) - An HTTP(S) URL (e.g. https://example.com/img.png) - A base64-encoded string (with or without data-URI prefix) question: What you want to know about the image. Default: "What is in this image?"

Returns: The vision model's answer as plain text.

Examples: >>> see_image("/tmp/screenshot.png", "What error is shown in this dialog?") >>> see_image("https://example.com/chart.png", "What's the trend?") >>> see_image("iVBORw0KGgo...", "Is this a cat or a dog?")

ParametersJSON Schema

Name	Required	Description	Default
`image`	Yes
`question`	No		What is in this image?

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description takes on the full burden. It transparently discloses accepted input formats (local paths, URLs, base64 strings), explicitly states the return type ('The vision model's answer as plain text'), and gives concrete examples. It does not discuss rate limits, authentication, or error behavior, but for a read-only vision tool this level of disclosure is reasonably informative.

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 well-structured with a one-sentence summary, a usage guideline, clearly labeled Args and Returns sections, and three illustrative examples. Every section earns its place without redundancy or filler. It is concisely written while still providing rich detail.

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 two-parameter tool with an output schema, the description is nearly complete: it covers input formats, default values, return type, and examples. It does not discuss potential limitations (e.g., file size limits, unsupported image types) or offer specific guidance for choosing among sibling vision tools, which would round it out. Given the tool's simplicity, this is a minor omission, hence a 4.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite the schema's low coverage (0%), the description substantially enriches both parameters. For 'image' it specifies three accepted formats (file path, URL, base64 with or without data-URI prefix) and for 'question' it clarifies semantics and provides a default. This goes far beyond the schema's bare 'string' type, fully compensating for the coverage gap.

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 opens with a specific verb-resource pair ('Look at an image and answer a question about it') and immediately positions it as the 'core vision tool' for understanding, describing, or reasoning about visual content. This clearly distinguishes it from sibling tools like extract_text (text extraction) and analyze_chart (chart analysis), even though it does not name them explicitly.

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 offers clear context: 'Use it whenever you need to understand, describe, or reason about visual content that you cannot see.' This tells the agent when to invoke the tool, but it does not provide explicit when-not-to-use scenarios or mention alternative tools by name. Thus it misses the 'explicit exclusions/alternatives' bar for a 5 but is strong enough for a 4.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation4/5

Most tools have distinct purposes: see_image for Q&A, extract_text for OCR, analyze_chart for charts/diagrams, and describe_image for general descriptions. However, see_image and describe_image overlap somewhat, as see_image with a default question essentially generates a description. The descriptions help clarify intent, so the ambiguity is limited.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in lowercase with underscores: see_image, extract_text, analyze_chart, describe_image. This makes the API predictable and easy to navigate.

Tool Count5/5

With 4 tools, the server is well-scoped for a vision MCP. Each tool covers a distinct core capability (Q&A, OCR, chart analysis, description) without unnecessary bloat. The count is appropriate for the domain.

Completeness4/5

The tool surface covers the major vision use cases: answering questions, extracting text, analyzing charts, and generating descriptions. Minor gaps exist, such as no explicit image comparison or object detection, but these are not core for a generic vision server. Overall, the coverage is solid with no dead ends.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
Wauldo
com.wauldo
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
Knowledge & Memory Autonomous Agents
2
Neonia: The Cloud Backend for AI Agents
io.neonia
Multiple MCP tools, persistent graph memory, token-saving data pointers, and more.
Knowledge & Memory Agent Orchestration Cloud Platforms
24
NinjaChat MCP
ai.ninjachat
Create images & video from any MCP agent — 17 models, spend limits, one URL.
Image & Video Processing AI & Machine Learning
1

Related MCP Servers

vision-bridge-mcp
Image & Video Processing AI & Machine Learning
zgz518
A
license
A
quality
B
maintenance
Enables non-multimodal models to see images by providing MCP tools for image understanding and OCR, backed by any OpenAI-compatible vision model.
Updated a month ago (2026-08-05 06:52 UTC)
2
MIT
vision-mcp
Image & Video Processing AI & Machine Learning
miaomiaozii
A
license
Not graded
quality
C
maintenance
Adds image recognition and UI grounding capabilities to text-only LLMs through MCP tools, supporting local and cloud vision backends.
Updated a month ago (2026-08-07 07:40 UTC)
32
MIT
vision-mcp
Image & Video Processing AI & Machine Learning
weekitmo
A
license
A
quality
B
maintenance
Vision MCP enables text-only agents to understand images through any OpenAI-compatible vision model. It supports local images, URLs, screenshots, documents, charts, and code errors with tools like analyze_image and understand_image.
Updated 19 days ago (2026-08-14 07:29 UTC)
2
MIT
Vision Bridge MCP
Image & Video Processing AI & Machine Learning
Hel10o
A
license
Not graded
quality
C
maintenance
Adds vision capabilities to text-only LLMs by integrating external vision models via MCP. It supports OCR, error screenshot reading, UI description, image comparison, and natural-language queries on images.
Updated 20 days ago (2026-08-13 10:01 UTC)
37
MIT

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/xiayuyang750/glm-vision-mcp'

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

GLM Vision MCP

How It Works

Quick Start

1. Install

2. Configure

3. Add to Your IDE

Cursor

Trae CN

Cline (VS Code)

Claude Desktop

Generic MCP Client (any MCP-compatible tool)

Supported Providers

Using a Custom Endpoint

Tools

see_image — Core Vision Tool

describe_image — Image Description

extract_text — OCR

analyze_chart — Chart & Diagram Analysis

Usage Example

Getting an API Key

Zhipu (智谱) — Free Tier Available

OpenAI

Development

Project Structure

Running Tests

Adding a New Provider

FAQ

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`see_image` — Core Vision Tool

`describe_image` — Image Description

`extract_text` — OCR

`analyze_chart` — Chart & Diagram Analysis