en es ja ru zh

clipboard-vision-mcp

Name: clipboard-vision-mcp
Author: Capetlevrai

by Capetlevrai

Overview Schema Source Related Servers Discussions Admin

Python

Local

clipboard-vision-mcp

🇫🇷 Versión francesa disponible → README.fr.md

Añade visión a modelos solo de texto en Opencode (DeepSeek V4, GLM 5.1) — ve la imagen en tu portapapeles directamente, sin guardar archivos manualmente.

Probado en Windows 11 + Opencode + DeepSeek V4 Pro. Soporte para portapapeles multi-SO (Windows / macOS / Linux X11 / Linux Wayland).

Derivado de itcomgroup/vision-mcp-server — reescrito en torno a herramientas centradas en el portapapeles, refuerzo de seguridad, extracción de portapapeles multiplataforma e instalación de IA con un solo prompt.

El problema

Los modelos económicos/rápidos solo de texto como DeepSeek V4 y GLM 5.1 son excelentes para código, pero no pueden leer imágenes. Cada vez que pegas una captura de pantalla, el modelo te pide que la guardes en el disco y proporciones una ruta.

Related MCP server: visual-understand-mcp

La solución

Este servidor MCP expone herramientas *_from_clipboard. Cuando el LLM necesita ver tu captura de pantalla, llama a analyze_clipboard: el servidor lee la imagen del portapapeles, la envía a un modelo de visión real (Groq + Llama-4 Scout, nivel gratuito) y devuelve una descripción de texto que el modelo de texto puede procesar.

Resultado: pegar → preguntar → listo. Sin mover archivos.

🤖 Instalación con un solo prompt mediante IA (recomendado)

En lugar de seguir los pasos a continuación manualmente, pega uno de estos prompts en cualquier asistente de codificación (DeepSeek, GLM, Claude, GPT, ...) y configurará todo de principio a fin: clonar, venv, dependencias, configuración de MCP, atajos de teclado:

¿Prefieres hacerlo tú mismo? Sigue leyendo.

Características

🖼️ Centrado en el portapapeles — analyze_clipboard, extract_text_from_clipboard, diagnose_error_from_clipboard, describe_ui_from_clipboard, code_from_clipboard.
📁 Respaldo de ruta de archivo — mismas herramientas disponibles para imágenes que ya están en el disco.
🆓 Backend de visión gratuito — Nivel gratuito de Groq con Llama-4 Scout (17B, multimodal).
🖥️ Multi-SO — Windows, macOS, Linux (X11 + Wayland).
🔒 Seguridad reforzada — validación de extensión/tamaño/bytes mágicos, eliminación automática de archivos temporales del portapapeles después del análisis.
🔌 Estándar MCP — funciona con Opencode, Claude Code, Cursor, Cline, Continue o cualquier cliente compatible con MCP.

Requisitos

Python 3.10+
Clave API de Groq (gratuita, registro en 30 segundos): https://console.groq.com/keys
Un cliente compatible con MCP (Opencode, Claude Code, Cursor, Cline, Continue, ...)

Dependencias de Python (instaladas automáticamente mediante `pip install -e .`)

Paquete	Propósito
`mcp>=1.0.0`	Servidor de protocolo MCP
`groq>=0.11.0`	Cliente API de Groq (visión Llama-4 Scout)
`aiofiles>=23.0.0`	E/S de archivos asíncrona
`Pillow>=10.0.0`	Extracción de imágenes del portapapeles (Windows/macOS), codificación PNG

Dependencias del portapapeles específicas del SO

SO	Comando	Por qué
Windows	nada extra	Pillow + pywin32 manejan el portapapeles de forma nativa.
macOS	`brew install pngpaste` (respaldo opcional)	Pillow funciona en la mayoría de los casos; pngpaste como respaldo.
Linux — Wayland	`sudo apt install wl-clipboard`	Proporciona `wl-paste`.
Linux — X11	`sudo apt install xclip`	O el equivalente de tu distribución.

Inicio rápido

1. Obtén una clave API de Groq gratuita

https://console.groq.com/keys

2. Instalación

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. Prueba de humo (no se necesita Groq)

Copia cualquier captura de pantalla, luego:

python examples/smoke_test.py

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

4. Conecta a tu cliente MCP

Consulta docs/OPENCODE.md para Opencode (probado en Windows) o docs/CLIENTS.md para Claude Code / Cursor / Cline / Continue.

Opencode (%APPDATA%\opencode\opencode.json en Windows, ~/.config/opencode/opencode.json en 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"
      }
    }
  }
}

💡 Usa la ruta absoluta al Python del venv. Esto garantiza que el MCP se inicie con las dependencias correctas independientemente del shell, el directorio de trabajo o el venv activo.

5. ⚠️ Atajos de teclado de Opencode para pegar imágenes

Opencode no vincula pegar imagen a Ctrl+V / Alt+V por defecto. Sin este paso, copiar una captura de pantalla y presionar pegar no insertará nada (o texto plano).

Edita tu keybinds.json de Opencode o la sección keybinds de opencode.json:

{
  "keybinds": {
    "input_paste": "ctrl+v",
    "input_paste_image": "alt+v"
  }
}

Reinicia Opencode después de editar.

6. ¿Se inicia automáticamente después de reiniciar Windows?

Sí. Opencode vuelve a leer opencode.json en cada inicio y genera automáticamente cualquier servidor MCP con "type": "local" y "enabled": true. Debido a que el comando usa la ruta absoluta al Python del venv, no importa desde qué shell o directorio de trabajo se inicie Opencode.

Reiniciar → abrir Opencode → las herramientas clipboard-vision aparecen listadas. Sin pasos manuales.

Uso

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

El modelo solo de texto nunca ve píxeles: lee la descripción devuelta por Llama-4 Scout y razona sobre ella.

Referencia de herramientas

Herramienta	Entrada	Usar cuando
`analyze_clipboard`	`prompt` opcional	Descripción genérica, preguntas y respuestas sobre la imagen del portapapeles.
`extract_text_from_clipboard`	—	OCR puro.
`describe_ui_from_clipboard`	—	Revisión de UI/UX, inventario de componentes.
`diagnose_error_from_clipboard`	—	Captura de pantalla de error → causa + solución.
`code_from_clipboard`	—	Extraer código de una captura de pantalla.
`analyze_image`	`image_path`, `prompt` opcional	Imagen ya en el disco.
`extract_text`, `describe_ui`, `diagnose_error`, `understand_diagram`, `analyze_chart`, `code_from_screenshot`	`image_path`	Igual que arriba para archivos.

Seguridad

Este servidor se ejecuta como un proceso stdio local: no abre ningún puerto de red y solo se comunica con el cliente MCP a través de stdin/stdout y con la API de Groq a través de HTTPS.

Refuerzos implementados:

Lista de permitidos de tipos de archivo. analyze_image y las otras herramientas de ruta de archivo solo aceptan .png .jpg .jpeg .gif .webp .bmp. Esto evita que un LLM con inyección de prompt le pida al servidor que lea archivos locales arbitrarios (~/.ssh/id_rsa, .env, ...) y los exfiltre como base64 a Groq.
Verificación de bytes mágicos. El contenido del archivo se valida contra encabezados de imagen conocidos antes de la carga.
Límite de tamaño. 20 MB máximo por imagen.
Eliminación automática de archivos temporales del portapapeles después de cada análisis. Las capturas de pantalla pueden contener secretos (tokens, chats, credenciales): el servidor los escribe en $TMPDIR/clipboard_vision_mcp/ y los elimina al finalizar.
Sin telemetría. Sin analíticas, sin llamadas a casa.

De qué no puede protegerte este proyecto

Tu clave API vive en la configuración de tu cliente MCP en texto plano. Así es como funcionan los clientes MCP hoy en día. Mantén ese archivo de configuración no legible para otros y nunca lo subas a un repositorio. Si expones accidentalmente una clave (chat, captura de pantalla, git push), rótala en https://console.groq.com/keys.
Groq recibe las imágenes que analizas. Consulta su política de privacidad antes de enviar algo sensible.
Cualquier herramienta MCP se ejecuta bajo la dirección del LLM. Si conectas un modelo con inyección de prompt a este servidor y le proporcionas entrada no confiable, el modelo puede elegir qué analizar. La lista de permitidos anterior reduce el radio de impacto pero no puede eliminarlo.

¿Encontraste un problema?

Por favor, abre un aviso de seguridad privado en lugar de un problema público.

Cómo funciona

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

Solución de problemas

"Clipboard does not contain an image." — Copia una imagen real, no un icono de archivo o texto. En Linux, verifica que wl-paste --type image/png o xclip -selection clipboard -t image/png -o | file - funcione fuera del MCP.
"GROQ_API_KEY is not set." — Verifica el bloque environment en la configuración de tu cliente, luego reinicia completamente el cliente.
Las herramientas no aparecen en Opencode. — Revisa los registros MCP de Opencode. Ejecuta python -m clipboard_vision_mcp manualmente: debería iniciarse y esperar silenciosamente en stdin.
"Refusing to read '' — only image files are allowed." — Tú (o el LLM) pasaste una ruta que no es una imagen. Este es el guardia de seguridad haciendo su trabajo.

Créditos

Derivado de itcomgroup/vision-mcp-server — integración original de Groq + Llama-4 Scout MCP.
Modelo de visión: Llama-4 Scout 17B servido por Groq.

Licencia

MIT — ver 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv0.1.0Apr 24, 2026
- First observedanalyze_chart
- First observedanalyze_clipboard
- First observedanalyze_image
- First observedcode_from_clipboard
- First observedcode_from_screenshot
- First observeddescribe_ui
- First observeddescribe_ui_from_clipboard
- First observeddiagnose_error
- First observeddiagnose_error_from_clipboard
- First observedextract_text
- First observedextract_text_from_clipboard
- First observedunderstand_diagram

Deploy Server

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

TDQS

B3.3/5.0

Scored 2026-04-24 16:20 across 12 tools

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

ActivitySlowing

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Frenchie A
io.github.Lab94
OCR, transcription, file extraction, and image generation for AI agents via MCP.
AI & Machine Learning Image & Video Processing Speech Processing
72
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
SammaPix — Image & PDF tools for AI agents
io.github.samma1997
Image & PDF tools for AI agents: compress, convert, resize, PDF, AI vision, pipeline.
Image & Video Processing AI & Machine Learning
17
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

Related MCP Servers

image-recognition-mcp
Image & Video Processing AI & Machine Learning
llt22
A
license
A
quality
D
maintenance
Gives vision-less LLMs the ability to recognize clipboard screenshots and images by proxying to an OpenAI-compatible vision model.
Updated 3 months ago (2026-07-01 07:01 UTC)
1
15 npm
2
MIT
visual-understand-mcp
Image & Video Processing AI & Machine Learning
bcdxc
F
license
A
quality
D
maintenance
Provides image understanding capabilities to coding models without vision support by automatically invoking a vision model and returning text descriptions, enabling seamless context-aware coding with images.
Updated 3 months ago (2026-06-25 01:27 UTC)
1
2
-
llm-vision-mcp
Image & Video Processing AI & Machine Learning Developer Tools
KuaaMU
A
license
A
quality
A
maintenance
Gives text-only LLM coding agents vision by routing images to a multimodal model and returning detailed textual descriptions. Supports local files, URLs, clipboard, base64, raw bytes, and multiple providers like OpenAI, Anthropic, and Gemini.
Updated a month ago (2026-08-08 13:09 UTC)
1
98 npm
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 2 months ago (2026-08-06 10:36 UTC)
1
MIT

clipboard-vision-mcp

El problema

La solución

🤖 Instalación con un solo prompt mediante IA (recomendado)

Características

Requisitos

Dependencias de Python (instaladas automáticamente mediante pip install -e .)

Dependencias del portapapeles específicas del SO

Inicio rápido

1. Obtén una clave API de Groq gratuita

2. Instalación

3. Prueba de humo (no se necesita Groq)

4. Conecta a tu cliente MCP

5. ⚠️ Atajos de teclado de Opencode para pegar imágenes

6. ¿Se inicia automáticamente después de reiniciar Windows?

Uso

Referencia de herramientas

Seguridad

De qué no puede protegerte este proyecto

¿Encontraste un problema?

Cómo funciona

Solución de problemas

Créditos

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Dependencias de Python (instaladas automáticamente mediante `pip install -e .`)