What can you do with this server?

This MCP server adds vision capabilities to text-only LLMs by analyzing clipboard images or local image files using Groq's free tier with Llama-4 Scout (17B multimodal) — no manual file saving required. Clipboard-based tools (no file path needed): * analyze_clipboard — Generic analysis or custom questions about the current clipboard image * extract_text_from_clipboard — OCR the clipboard image * describe_ui_from_clipboard — Describe UI layout, components, and state * diagnose_error_from_clipboard — Interpret error screenshots and suggest fixes * code_from_clipboard — Extract and identify code from a clipboard screenshot File-based tools (image already on disk): * analyze_image — General analysis with optional custom prompt * extract_text — OCR an image file * describe_ui — Describe UI from a screenshot file * diagnose_error — Diagnose an error from a screenshot file * understand_diagram — Interpret and explain a diagram * analyze_chart — Extract insights from a chart * code_from_screenshot — Extract code from a screenshot file Additional highlights: * Security: File type allow-listing, magic-byte checks, 20MB size cap, auto-deletion of temporary clipboard files * Cross-platform: Windows, macOS, and Linux (X11 & Wayland) * MCP compatible: Works with Opencode, Claude Code, Cursor, Cline, Continue, and other MCP-capable clients

How do I use clipboard-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., "@clipboard-vision-mcp describe the image in my clipboard" 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.

en es ja ru zh

clipboard-vision-mcp

by Capetlevrai

Overview Schema Related Servers Score Discussions

Python

Local

clipboard-vision-mcp

🇫🇷 Version française disponible → README.fr.md

Add vision to text-only models in Opencode (DeepSeek V4, GLM 5.3) — see the image in your clipboard directly, no manual file saving.

Tested on Windows 11 + Opencode + DeepSeek V4 Pro. Multi-OS clipboard support (Windows / macOS / Linux X11 / Linux Wayland).

Forked from itcomgroup/vision-mcp-server — rewritten around clipboard-first tools, security hardening, cross-platform clipboard extraction, and one-prompt AI install.

The problem

Cheap/fast text-only models like DeepSeek V4 and GLM 5.3 are great for code, but they cannot read images. Every time you paste a screenshot, the model asks you to save it to disk and provide a path.

Related MCP server: visual-understand-mcp

The fix

This MCP server exposes *_from_clipboard tools. When the LLM needs to see your screenshot, it calls analyze_clipboard — the server reads the clipboard image, sends it to a real vision model (Groq + Qwen 3.6 27B, free tier), and returns a text description the text model can reason about.

Result: paste → ask → done. No file shuffling.

🤖 One-prompt install via AI (recommended)

Instead of running the steps below manually, paste one of these prompts into any coding assistant (DeepSeek, GLM, Claude, GPT, ...) and it will set everything up for you end-to-end — clone, venv, deps, MCP config, keybindings:

🇬🇧 docs/INSTALL_PROMPT_EN.md
🇫🇷 docs/INSTALL_PROMPT_FR.md

Prefer doing it yourself? Keep reading.

Features

🖼️ Clipboard-first — analyze_clipboard, extract_text_from_clipboard, diagnose_error_from_clipboard, describe_ui_from_clipboard, code_from_clipboard.
📁 File path fallback — same tools available for images already on disk.
🆓 Free vision backend — Groq's free tier with Qwen 3.6 27B (27B multimodal, 131K context).
🔁 Model is swappable — set GROQ_VISION_MODEL to follow Groq's catalog without touching the code.
🖥️ Multi-OS — Windows, macOS, Linux (X11 + Wayland).
🔒 Security hardened — extension/size/magic-byte validation, auto-delete of clipboard temp files after analysis.
🔌 MCP standard — works with Opencode, Claude Code, Cursor, Cline, Continue, or any MCP-capable client.

Requirements

Python 3.10+
Groq API key (free, 30 seconds sign-up): https://console.groq.com/keys
An MCP-capable client (Opencode, Claude Code, Cursor, Cline, Continue, ...)

Python dependencies (installed automatically via `pip install -e .`)

Package	Purpose
`mcp>=1.0.0`	MCP protocol server
`groq>=0.11.0`	Groq API client (Qwen 3.6 27B vision)
`aiofiles>=23.0.0`	Async file I/O
`Pillow>=10.0.0`	Clipboard image extraction (Windows/macOS), PNG encoding

OS-specific clipboard dependencies

OS	Command	Why
Windows	nothing extra	Pillow + pywin32 handle the clipboard natively.
macOS	`brew install pngpaste` (optional fallback)	Pillow works in most cases; pngpaste as backup.
Linux — Wayland	`sudo apt install wl-clipboard`	Provides `wl-paste`.
Linux — X11	`sudo apt install xclip`	Or your distro equivalent.

Quick start

1. Get a free Groq API key

https://console.groq.com/keys

2. Install

git clone https://github.com/Capetlevrai/clipboard-vision-mcp.git
cd clipboard-vision-mcp
python -m venv .venv
# Windows:
.venv\Scripts\activate
# macOS/Linux:
source .venv/bin/activate
pip install -e .

3. Smoke test (no Groq needed)

Copy any screenshot, then:

python examples/smoke_test.py

Expected: OK: clipboard image saved to <path>.

4. Wire to your MCP client

See docs/OPENCODE.md for Opencode (Windows-tested) or docs/CLIENTS.md for Claude Code / Cursor / Cline / Continue.

Opencode (%APPDATA%\opencode\opencode.json on Windows, ~/.config/opencode/opencode.json on Linux/macOS):

{
  "mcp": {
    "clipboard-vision": {
      "type": "local",
      "command": [
        "C:\\path\\to\\clipboard-vision-mcp\\.venv\\Scripts\\python.exe",
        "-m",
        "clipboard_vision_mcp"
      ],
      "enabled": true,
      "environment": {
        "GROQ_API_KEY": "gsk_your_key_here"
      }
    }
  }
}

💡 Use the absolute path to the venv's Python. This guarantees the MCP starts with the right dependencies regardless of shell, cwd, or active venv.

4b. Changing the vision model (optional)

The model id is read once at startup from GROQ_VISION_MODEL, defaulting to qwen/qwen3.6-27b. Add it to the same environment block to pin a different one:

"environment": {
  "GROQ_API_KEY": "gsk_your_key_here",
  "GROQ_VISION_MODEL": "qwen/qwen3.6-27b"
}

Useful when Groq retires a model — as happened to meta-llama/llama-4-scout-17b-16e-instruct on 2026-06-17. Pick any vision model from https://console.groq.com/docs/models; no code change required. The older VISION_MODEL name still works as a fallback.

5. ⚠️ Opencode keybindings for pasting images (Alt+V)

Two important facts about opencode (these are easy to get wrong):

Keybinds live in tui.json (next to opencode.json), NOT in opencode.json. opencode.json rejects unknown top-level keys, so adding a keybinds block there makes opencode refuse to start (ConfigInvalidError).
There is no input_paste_image action. Pasting (text and images) is the single input_paste action — opencode's TUI reads the image straight from the OS clipboard. It is bound to Ctrl+V by default; to also paste with Alt+V, bind input_paste to both.

Create/merge tui.json (e.g. ~/.config/opencode/tui.json on Linux/macOS, C:\Users\<you>\.config\opencode\tui.json on Windows):

{
  "$schema": "https://opencode.ai/tui.json",
  "keybinds": {
    "input_paste": [
      { "key": "ctrl+v", "preventDefault": false },
      { "key": "alt+v", "preventDefault": false }
    ]
  }
}

Restart Opencode after editing. Then copy a screenshot and press Alt+V (or Ctrl+V) in the prompt — the image attaches.

ℹ️ Optional: the *_from_clipboard tools read the OS clipboard themselves, so you can skip pasting entirely — just copy a screenshot and ask the model to "analyze my clipboard".

6. Does it auto-start after a Windows reboot?

Yes. Opencode re-reads opencode.json at every launch and auto-spawns any MCP server with "type": "local" and "enabled": true. Because the command uses the absolute path to the venv's Python, it doesn't matter which shell or working directory Opencode is launched from.

Reboot → open Opencode → clipboard-vision tools are listed. No manual step.

Usage

You: (copy a screenshot to clipboard, then type)
     "Look at what I just copied and tell me what's wrong with this error."

LLM (DeepSeek, GLM, Claude, ...): [calls diagnose_error_from_clipboard]
     → "The error says `ECONNREFUSED 127.0.0.1:5432`. Postgres isn't
        running on port 5432. Start it with: ..."

The text-only model never sees pixels — it reads the description returned by Qwen 3.6 27B and reasons over it.

Tool reference

Tool	Input	Use when
`analyze_clipboard`	optional `prompt`	Generic description, Q&A on the clipboard image.
`extract_text_from_clipboard`	—	Pure OCR.
`describe_ui_from_clipboard`	—	UI/UX review, component inventory.
`diagnose_error_from_clipboard`	—	Error screenshot → cause + fix.
`code_from_clipboard`	—	Extract code from a screenshot.
`analyze_image`	`image_path`, optional `prompt`	Image already on disk.
`extract_text`, `describe_ui`, `diagnose_error`, `understand_diagram`, `analyze_chart`, `code_from_screenshot`	`image_path`	Same as above for files.

Security

This server runs as a local stdio process — it does not open any network port and only talks to the MCP client over stdin/stdout and to the Groq API over HTTPS.

Hardening in place:

File type allow-list. analyze_image and the other file-path tools only accept .png .jpg .jpeg .gif .webp .bmp. This prevents a prompt-injected LLM from asking the server to read arbitrary local files (~/.ssh/id_rsa, .env, ...) and exfiltrate them as base64 to Groq.
Magic-byte check. File content is validated against known image headers before upload.
Size cap. 20 MB max per image.
Auto-delete clipboard temp files after each analysis. Screenshots may contain secrets (tokens, chats, credentials) — the server writes them to $TMPDIR/clipboard_vision_mcp/ and unlinks them on completion.
No telemetry. No analytics, no phone-home.

What this project cannot protect you from

Your API key lives in your MCP client config in plain text. That is how MCP clients work today. Keep that config file non-world-readable and never commit it. If you accidentally expose a key (chat, screenshot, git push), rotate it at https://console.groq.com/keys.
Groq receives the images you analyze. Check their privacy policy before sending anything sensitive.
Any MCP tool is executed at the direction of the LLM. If you connect a prompt-injected model to this server and feed it untrusted input, the model can choose what to analyze. The allow-list above reduces blast radius but cannot eliminate it.

Found an issue?

Please open a private security advisory rather than a public issue.

How it works

┌──────────────┐   MCP   ┌─────────────────┐   HTTPS   ┌─────────────────┐
│  Opencode    │ ──────▶ │  clipboard-     │ ────────▶ │  Groq API       │
│  (DeepSeek)  │         │  vision-mcp     │           │  Qwen 3.6 27B   │
└──────────────┘         └─────────────────┘           └─────────────────┘
                              │
                              ▼
                     reads system clipboard
                     (PIL / wl-paste / xclip)
                     → validate → base64 → send → delete

Troubleshooting

"Clipboard does not contain an image." — Copy an actual image, not a file icon or text. On Linux, verify wl-paste --type image/png or xclip -selection clipboard -t image/png -o | file - works outside the MCP.
"GROQ_API_KEY is not set." — Check the environment block in your client config, then fully restart the client.
Tools don't appear in Opencode. — Check Opencode's MCP logs. Run python -m clipboard_vision_mcp manually — it should start and wait silently on stdin.
"Refusing to read '' — only image files are allowed." — You (or the LLM) passed a non-image path. This is the security guard doing its job.
model_not_found / model has been decommissioned. — Groq retired the configured vision model (this is what killed meta-llama/llama-4-scout-17b-16e-instruct on 2026-06-17). Set GROQ_VISION_MODEL to a current id from https://console.groq.com/docs/models and restart the client.

Credits

Forked from itcomgroup/vision-mcp-server — original Groq + Llama-4 Scout MCP integration.
Vision model: Qwen 3.6 27B served by Groq (replaces Llama-4 Scout 17B, deprecated 2026-06-17).

License

MIT — see LICENSE.

Available Tools

12 tools

analyze_chartC

Analyze a chart image file.

ParametersJSON Schema

Name	Required	Description	Default
`image_path`	Yes	Absolute path to the image file.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must carry behavioral disclosure. It only states the action but does not describe side effects, output format, or if the operation is 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with no extraneous content. It is efficient, though it could benefit from slightly more detail without being verbose.

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 simple tool (one parameter, no output schema), the description is too brief. It does not explain what 'analyze' entails (e.g., extract text, generate summary), leaving the agent uncertain about the output.

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 a clear parameter description. The tool description adds no additional meaning beyond what the schema already provides, meeting the baseline for high coverage.

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 tool name and description clearly state it analyzes a chart image file. However, it does not differentiate from sibling tools like 'analyze_image' or 'describe_ui', which may have similar functionality.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool over alternatives. The description lacks context about prerequisites or exclusions.

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

analyze_clipboardA

Read the image currently in the system clipboard and analyze it. Use this when the user says 'look at this', 'what's in my clipboard', or pastes a screenshot without providing a file path. Optional prompt overrides the default description request.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	No	Custom question about the clipboard image.

TDQS

A3.9/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavior but only states 'read and analyze'. It does not mention side effects, permissions, return type, or limitations.

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 concise sentences, front-loaded with primary action, no wasted words.

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?

No output schema, so description should hint at return type. It only says 'analyze it', leaving ambiguity about what the agent receives back. Adequate but not complete.

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?

Schema covers 100% of parameters, and description adds value by explaining that the default analysis is a description request and the prompt parameter overrides it.

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 reads and analyzes the clipboard image, with explicit example triggers like 'look at this' and 'what's in my clipboard'. This distinguishes it from siblings like 'code_from_clipboard' or 'analyze_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?

It specifies when to use (user says certain phrases or pastes screenshot without file path) and mentions optional prompt override. However, it does not explicitly exclude situations where sibling tools would be better.

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

analyze_imageC

Analyze an image file. Provide image_path and optional prompt.

ParametersJSON Schema

Name	Required	Description	Default
`image_path`	Yes
`prompt`	No

TDQS

C2.5/5.0

Behavior1/5

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

No annotations are present, and the description does not disclose behavioral traits such as read-only status, required permissions, performance characteristics, or side effects. The description only states the action without any operational context.

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, consisting of a single sentence that front-loads the purpose. It avoids unnecessary words, but the brevity leaves out important details.

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's potential complexity (image analysis), the lack of output schema and minimal description make it incomplete. The agent does not know what the tool returns or any constraints (e.g., file size limits, supported formats).

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

Parameters2/5

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

Schema description coverage is 0%, yet the description only reiterates that image_path is required and prompt is optional. It does not explain what valid values for image_path (e.g., file path vs URL) or how the prompt influences analysis. This adds minimal value beyond the schema.

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 verb 'Analyze' and the resource 'image file', making the purpose understandable. However, it does not differentiate from sibling tools like analyze_chart or code_from_screenshot, which also involve image analysis.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus its siblings (e.g., analyze_chart, code_from_screenshot). There is no mention of prerequisites or context in which this tool is appropriate.

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

code_from_clipboardB

Extract code from a clipboard screenshot, identifying the language.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description must disclose all behavioral traits. It states the action and outcome but omits details about how the clipboard is accessed, potential error cases (e.g., no image in clipboard, unsupported format), and whether any side effects occur. The tool's behavior is partially transparent but lacks completeness.

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 of 7 words, extremely concise. It front-loads the primary action 'Extract code' and adds the key detail 'identifying the language'. While efficient, it is so brief that some context is missed, preventing a perfect score.

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 no parameters and no output schema, the description should at least clarify the input source (e.g., reads current clipboard content). It does not explicitly state that the tool reads from the clipboard automatically, though the name implies it. Sibling tools provide more context, making this one minimally complete but adequate for basic understanding.

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 input schema has no parameters, so the description need not add parameter meaning. Since there are 0 parameters, the description is not required to elaborate. The baseline of 4 is appropriate as it does not mislead or omit necessary parameter information.

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 extracts code from a clipboard screenshot and identifies the language. It specifies the verb 'extract', the resource 'code from clipboard screenshot', and the additional outcome 'identifying the language'. This clearly distinguishes it from siblings like 'code_from_screenshot' which loads from file, and 'extract_text_from_clipboard' which is for general text.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'code_from_screenshot' or 'analyze_clipboard'. It does not mention prerequisites, like having a valid screenshot in the clipboard, nor does it specify when not to use it. Usage is only implied.

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

code_from_screenshotB

Extract code from a screenshot file.

ParametersJSON Schema

Name	Required	Description	Default
`image_path`	Yes	Absolute path to the image file.

TDQS

B3.2/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 disclosing behavior. It does not mention that this likely uses OCR, supported image formats, accuracy limitations, or whether it returns textual code or a file path.

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 extremely concise (one sentence) and front-loaded with the key information. It is not verbose, though it could be expanded without losing efficiency.

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's simplicity (single parameter, no output schema), the description is minimally adequate but lacks details about return value (e.g., raw text or code snippet) and edge cases.

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% (image_path described adequately), but the description adds no additional meaning, such as the expected image format or path syntax. Baseline 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 uses a specific verb 'Extract' and resource 'code from a screenshot file', clearly stating the tool's function. It implicitly distinguishes from sibling tools like 'code_from_clipboard' by specifying the source as a file.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'code_from_clipboard', 'extract_text', or 'analyze_image'. No context about prerequisites or exclusions is given.

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

describe_uiC

Describe a UI screenshot file.

ParametersJSON Schema

Name	Required	Description	Default
`image_path`	Yes	Absolute path to the image file.

TDQS

C2.6/5.0

Behavior1/5

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

With no annotations, the description carries full burden of behavioral disclosure, yet it only states 'describe' without indicating output format, response limitations, or any behavioral traits. This is insufficient for an agent to understand what the tool does beyond the simple verb.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with one sentence, but it lacks structure and additional needed context. It is not verbose, but the conciseness comes at the cost of missing critical information.

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 simplicity and full schema coverage, the description is incomplete. It omits output details (e.g., format, content), fails to differentiate from siblings, and does not leverage the schema to provide richer context.

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 a clear parameter description ('Absolute path to the image file'). The tool description adds no extra meaning beyond the schema, so it meets the baseline of 3 but does not elevate it.

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 verb 'describe' and the resource 'UI screenshot file'. However, it does not distinguish itself from sibling tools like analyze_image or describe_ui_from_clipboard, as it lacks specific scope or method differentiation.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. Siblings such as describe_ui_from_clipboard (clipboard input) and analyze_image (broader analysis) exist, but no usage context, prerequisites, or exclusions are given.

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

describe_ui_from_clipboardA

Describe the UI in a clipboard screenshot (layout, components, state).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided. Description only states it describes, implying read-only, but does not disclose behavior for invalid clipboard content, side effects, or prerequisites.

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?

Single sentence of 10 words, directly conveys purpose with no unnecessary words.

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 zero-parameter tool, description covers core purpose. Lacks output format or constraints, but adequate given simplicity.

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?

Input schema has zero parameters, so schema coverage is 100%. Description adds no parameter info, but baseline for 0 params is 4.

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 verb 'describe', resource 'UI in a clipboard screenshot', and aspects 'layout, components, state'. It distinguishes from sibling tools like 'describe_ui' (without clipboard) and 'analyze_clipboard'.

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?

Implicitly indicates use when clipboard holds a UI screenshot, but no explicit when-not-to-use or alternatives. Siblings exist but not referenced.

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

diagnose_errorC

Diagnose an error screenshot file.

ParametersJSON Schema

Name	Required	Description	Default
`image_path`	Yes	Absolute path to the image file.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must disclose behavior. It only states 'diagnose' without indicating side effects (e.g., read-only), required permissions, or output format. This is insufficient for safe invocation.

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, front-loaded sentence with no redundancy. However, it could include more context without sacrificing conciseness.

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?

For a tool with one parameter and no output schema, the description lacks details on what 'diagnose' returns (e.g., error analysis, possible fix). It feels incomplete as an instruction.

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% and the description adds no additional meaning beyond the schema's 'Absolute path to the image file.' Baseline score applies.

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 action (diagnose) and the resource (error screenshot file). It is distinct from sibling tools like 'diagnose_error_from_clipboard' which uses clipboard input, so purpose is clear but could specify what 'diagnose' entails.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives such as 'diagnose_error_from_clipboard' or 'analyze_image'. The agent must infer from the parameter type.

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

diagnose_error_from_clipboardB

Diagnose an error screenshot from the clipboard and propose fixes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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

Lacks annotations. Description only says it diagnoses and proposes fixes, but does not disclose how it processes the clipboard (e.g., reads image, text), what types of errors, or any side effects.

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?

Single sentence conveying essential purpose clearly. No wasted words.

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?

Simple tool but no annotations or output schema. For a diagnostic tool that proposes fixes, more detail on return format or error scope would improve completeness.

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?

No parameters, so schema coverage is 100%. The description does not need to explain parameters, but it could hint that the input is read automatically from clipboard.

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?

Clearly states it diagnoses error screenshots from clipboard and proposes fixes. However, the sibling 'diagnose_error' likely performs similar analysis but without clipboard, and the description does not differentiate.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like 'diagnose_error' or other clipboard analysis tools. Implied usage when clipboard has an error screenshot, but no explicit context.

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

extract_textC

OCR an image file.

ParametersJSON Schema

Name	Required	Description	Default
`image_path`	Yes	Absolute path to the image file.

TDQS

C2.9/5.0

Behavior2/5

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

The description simply states 'OCR an image file' without disclosing behavioral traits such as supported image formats, file size limits, performance characteristics, or error handling. Since no annotations are provided, the description carries the full burden but adds minimal 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at four words, front-loading the core purpose. However, it could be improved by including a brief sentence on usage or output. Still, it avoids verbosity and earns its place.

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's simplicity (one parameter, no output schema), the description could provide minimal context about the output (e.g., extracted text) or common use cases. The current description lacks completeness, leaving the agent unaware of what the tool returns or any constraints.

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% coverage (the 'image_path' parameter is described as 'Absolute path to the image file.'). The description does not add any extra semantic value beyond the schema, but the schema itself is sufficient. According to the guidelines, high schema coverage sets a baseline of 3.

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?

Describes the tool as 'OCR an image file,' which clearly indicates the specific operation (OCR) and the resource (image file). However, it does not differentiate from siblings like 'extract_text_from_clipboard' or 'analyze_image,' which could cause confusion about which tool to use.

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

Usage Guidelines2/5

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

No usage context is provided. The description does not specify when to use this file-based tool versus clipboard alternatives, nor does it mention any prerequisites (e.g., valid image format) or conditions for effective use.

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

extract_text_from_clipboardA

OCR the image currently in the clipboard and return only its text.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided, so description must convey all behavioral details. It only states the core function, omitting what happens if no image, OCR failure, or output format. For a tool with no annotations, this is insufficient.

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?

A single sentence efficiently conveys the full purpose with no redundancy. Every word earns its place.

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 no parameters or output schema, the description is largely complete. It explains input (clipboard image) and output (text). However, lacks details on error cases or prerequisites, which would be helpful for a standalone 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?

The tool has zero parameters with 100% schema coverage, so baseline is 4. The description adds no parameter info but is unnecessary. It clearly conveys that the clipboard image is the implicit input.

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 performs OCR on the clipboard image and returns text. The verb 'OCR' and resource 'image in clipboard' are specific, distinguishing it from siblings like 'extract_text' or 'code_from_clipboard'.

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?

Usage is implied (when you have an image with text in clipboard), but lacks explicit when-not-to-use or alternatives. No mention of alternatives like 'extract_text' for other sources or 'analyze_clipboard' for different analysis.

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

understand_diagramC

Interpret a diagram image file.

ParametersJSON Schema

Name	Required	Description	Default
`image_path`	Yes	Absolute path to the image file.

TDQS

C2.3/5.0

Behavior1/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 'interpret,' offering no information about side effects, required permissions, or output nature. This is severely insufficient for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, efficient but under-specified. It lacks crucial details that would warrant a longer description, so it is not excessively verbose, but its brevity compromises completeness. A 3 reflects adequate conciseness with room for 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's simplicity (one parameter, no output schema) and the presence of similar siblings, the description fails to provide enough context for correct usage. It omits return behavior, typical use cases, and differentiation from closely related tools, making it incomplete.

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 description covers the single parameter 'image_path' at 100%, but the tool description adds no additional context about accepted formats, file size limits, or path conventions. With high schema coverage, a baseline of 3 is appropriate as the description provides no extra value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description specifies 'interpret a diagram image file,' which narrows the scope to diagrams, distinguishing it from siblings like analyze_chart or analyze_image. However, 'interpret' is vague and does not clarify the tool's exact function, such as extracting text, recognizing shapes, or providing a semantic summary.

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

Usage Guidelines2/5

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

The description provides no usage guidance, such as when to use this tool versus alternatives like analyze_chart or analyze_image. It does not mention prerequisites, context, or when not to use it, leaving the agent to infer from sibling names alone.

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

B3.3/5.0

Disambiguation4/5

Tools are mostly distinct, but analyze_clipboard (general clipboard analyzer) overlaps with specialized clipboard tools like code_from_clipboard and describe_ui_from_clipboard, potentially confusing an agent about which to use for a broad request.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., analyze_chart, extract_text, describe_ui_from_clipboard), with predictable suffixes for clipboard variants.

Tool Count5/5

12 tools is a well-scoped count for an image analysis server covering both file and clipboard inputs for common specialized tasks (text, code, UI, errors, diagrams) plus general analysis.

Completeness4/5

The set covers most common image analysis needs, but lacks clipboard-specific tools for chart and diagram analysis (only file versions exist), leaving a minor gap that the general analyze_clipboard can fill but with less specificity.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

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
Avocado AI
io.github.Wandersonjack
Generate AI images, videos, music, SFX & speech in any AI assistant. Results appear inline in chat.
AI & Machine Learning Image & Video Processing Marketing
2
Codex Imagem A
io.github.mcp-dir
Generate images with your own ChatGPT subscription (Plus, Pro or Team), without spending API credits
AI & Machine Learning Image & Video Processing
81
Goodeye A
dev.goodeye
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
Agent Orchestration AI & Machine Learning Image & Video Processing
24

Related MCP Servers

image-recognition-mcp
Image & Video Processing AI & Machine Learning
llt22
A
license
A
quality
B
maintenance
Gives vision-less LLMs the ability to recognize clipboard screenshots and images by proxying to an OpenAI-compatible vision model.
Updated 2 months ago (2026-07-01 07:01 UTC)
1
24
2
MIT
visual-understand-mcp
Image & Video Processing AI & Machine Learning
bcdxc
F
license
A
quality
B
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 2 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
99
12
MIT
opencode-vision-mcp
Image & Video Processing AI & Machine Learning
Jsliu28
A
license
Not graded
quality
B
maintenance
Enables text-only models to understand images by intercepting pasted images, saving them locally, and using a vision MCP server to analyze them with multimodal backends like Qwen-VL, Doubao, or GLM-4V.
Updated a month ago (2026-08-06 10:36 UTC)
1
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/Capetlevrai/clipboard-vision-mcp'

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

clipboard-vision-mcp

The problem

The fix

🤖 One-prompt install via AI (recommended)

Features

Requirements

Python dependencies (installed automatically via pip install -e .)

OS-specific clipboard dependencies

Quick start

1. Get a free Groq API key

2. Install

3. Smoke test (no Groq needed)

4. Wire to your MCP client

4b. Changing the vision model (optional)

5. ⚠️ Opencode keybindings for pasting images (Alt+V)

6. Does it auto-start after a Windows reboot?

Usage

Tool reference

Security

What this project cannot protect you from

Found an issue?

How it works

Troubleshooting

Credits

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Python dependencies (installed automatically via `pip install -e .`)