MCP Image Recognition Server
Servidor de reconocimiento de imágenes MCP
Un servidor MCP que ofrece capacidades de reconocimiento de imágenes mediante las API de visión de IA de Anthropic, OpenAI y Cloudflare Workers. Versión 1.2.1.

Autores
Originalmente este proyecto fue creado por @mario-andreschak . ¡Gracias!
Actualmente lo mantiene @zudsniper .
Related MCP server: Image Parse MCP
Características
Descripción de la imagen utilizando Anthropic Claude Vision, OpenAI GPT-4 Vision o Cloudflare Workers AI llava-1.5-7b-hf
Fácil integración con Claude Desktop, Cursor y otros clientes compatibles con MCP
Soporte para la implementación de Docker
Soporte para la instalación de uvx
Compatibilidad con múltiples formatos de imagen (JPEG, PNG, GIF, WebP)
Proveedores primarios y de respaldo configurables
Compatibilidad con entrada de imágenes basada en archivos y Base64
Extracción de texto opcional mediante Tesseract OCR
Requisitos
Python 3.8 o superior
Tesseract OCR (opcional): necesario para la función de extracción de texto
Windows: Descargar e instalar desde UB-Mannheim/tesseract
Linux:
sudo apt-get install tesseract-ocrmacOS:
brew install tesseract
Instalación
Opción 1: Usar uvx (recomendado para Claude Desktop y Cursor)
Instalar el administrador de paquetes uv :
pip install uvInstalar el paquete con uvx:
uvx install mcp-image-recognitionCree y configure su archivo de entorno como se describe en la sección Configuración
Opción 2: Usar Docker
docker pull zudsniper/mcp-image-recognition:latest
# Create a .env file first, then run:
docker run -it --env-file .env zudsniper/mcp-image-recognitionOpción 3: Desde la fuente
Clonar el repositorio:
git clone https://github.com/zudsniper/mcp-image-recognition.git
cd mcp-image-recognitionCrea y configura tu archivo de entorno:
cp .env.example .env
# Edit .env with your API keys and preferencesConstruir el proyecto:
pip install -e .Integración
Integración de escritorio de Claude
Vaya a Claude > Configuración > Desarrollador > Editar configuración > claude_desktop_config.json
Agregar configuración con variables de entorno en línea:
{
"mcpServers": {
"image-recognition": {
"command": "uvx",
"args": [
"mcp-image-recognition"
],
"env": {
"VISION_PROVIDER": "openai",
"OPENAI_API_KEY": "your-api-key",
"OPENAI_MODEL": "gpt-4o"
}
}
}
}Integración del cursor
Vaya a Configuración del cursor > MCP y pegue con variables de entorno:
VISION_PROVIDER=openai OPENAI_API_KEY=your-api-key OPENAI_MODEL=gpt-4o uvx mcp-image-recognitionIntegración de Docker
Opción 1: Usar la imagen de DockerHub
Agregue esto a su configuración de Claude Desktop con entorno en línea:
{
"mcpServers": {
"image-recognition": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"zudsniper/mcp-image-recognition:latest"
],
"env": {
"VISION_PROVIDER": "openai",
"OPENAI_API_KEY": "your-api-key",
"OPENAI_MODEL": "gpt-4o"
}
}
}
}Para la configuración de Cloudflare:
"env": {
"VISION_PROVIDER": "cloudflare",
"CLOUDFLARE_API_KEY": "your-api-key",
"CLOUDFLARE_ACCOUNT_ID": "your-account-id"
}Uso
Ejecutar el servidor directamente
Si se instala con pip/uvx:
mcp-image-recognitionDesde el directorio de origen:
python -m image_recognition_server.serverUsando Docker:
docker run -it --env-file .env zudsniper/mcp-image-recognitionComience en modo de desarrollo con el Inspector MCP:
npx @modelcontextprotocol/inspector mcp-image-recognitionHerramientas disponibles
describe_imagePropósito : Analizar imágenes cargadas directamente al chat.
Entrada : datos de imagen codificados en Base64
Salida : Descripción detallada de la imagen.
Ideal para : imágenes cargadas directamente en Claude, Cursor u otras interfaces de chat
describe_image_from_filePropósito : Procesar archivos de imagen locales del sistema de archivos
Entrada : Ruta a un archivo de imagen
Salida : Descripción detallada de la imagen.
Ideal para : desarrollo local con acceso al sistema de archivos
Nota : Cuando se ejecuta en Docker, se requiere mapeo de volumen (consulte la sección Acceso a archivos de Docker)
describe_image_from_urlPropósito : Analizar imágenes desde URLs web sin descargarlas manualmente
Entrada : URL de una imagen de acceso público
Salida : Descripción detallada de la imagen.
Ideal para : imágenes web, capturas de pantalla o cualquier cosa con una URL pública.
Nota : utiliza encabezados similares a los del navegador para evitar la limitación de velocidad.
Configuración del entorno
ANTHROPIC_API_KEY: Su clave API antrópica.OPENAI_API_KEY: Su clave API de OpenAI.CLOUDFLARE_API_KEY: Su clave API de Cloudflare.CLOUDFLARE_ACCOUNT_ID: Su ID de cuenta de Cloudflare.VISION_PROVIDER: Proveedor de visión principal (anthropic,openaiocloudflare).FALLBACK_PROVIDER: Proveedor de respaldo opcional.LOG_LEVEL: Nivel de registro (DEBUG, INFO, WARNING, ERROR).ENABLE_OCR: habilita la extracción de texto OCR de Tesseract (trueofalse).TESSERACT_CMD: Ruta personalizada opcional al ejecutable de Tesseract.OPENAI_MODEL: Modelo OpenAI (predeterminado:gpt-4o-mini). Se puede usar el formato OpenRouter para otros modelos (p. ej.,anthropic/claude-3.5-sonnet:beta).OPENAI_BASE_URL: URL base personalizada opcional para la API de OpenAI. Establézcala enhttps://openrouter.ai/api/v1para OpenRouter.OPENAI_TIMEOUT: Tiempo de espera personalizado opcional (en segundos) para la API de OpenAI.CLOUDFLARE_MODEL: modelo de IA de Cloudflare Workers (predeterminado:@cf/llava-hf/llava-1.5-7b-hf).CLOUDFLARE_MAX_TOKENS: Número máximo de tokens a generar (predeterminado:512).CLOUDFLARE_TIMEOUT: Tiempo de espera para las solicitudes de API de Cloudflare en segundos (valor predeterminado:60).
Uso de OpenRouter
OpenRouter permite acceder a varios modelos mediante el formato de la API de OpenAI. Para usar OpenRouter, siga estos pasos:
Obtenga una clave API de OpenAI de OpenRouter.
Establezca
OPENAI_API_KEYen su archivo.enven su clave API de OpenRouter.Establezca
OPENAI_BASE_URLenhttps://openrouter.ai/api/v1.Establezca
OPENAI_MODELen el modelo deseado utilizando el formato OpenRouter (por ejemplo,anthropic/claude-3.5-sonnet:beta).Establezca
VISION_PROVIDERenopenai.
Modelos predeterminados
Antrópico:
claude-3.5-sonnet-betaOpenAI:
gpt-4o-miniIA de los trabajadores de Cloudflare:
@cf/llava-hf/llava-1.5-7b-hfOpenRouter: utilice el formato
anthropic/claude-3.5-sonnet:betaenOPENAI_MODEL.
Desarrollo
Guía de configuración del desarrollo
Configuración del entorno de desarrollo
Clonar el repositorio:
git clone https://github.com/zudsniper/mcp-image-recognition.git
cd mcp-image-recognitionConfiguración con uv (recomendado):
# Install uv if not installed
pip install uv
# Create virtual environment and install deps
uv venv
uv venv activate
uv pip install -e .
uv pip install -e ".[dev]"Configuración alternativa con pip:
python -m venv venv source venv/bin/activate # On Windows: venv\Scripts\activate pip install -e . # Or alternatively: pip install -r requirements.txt pip install -r requirements-dev.txt
Configurar el entorno:
cp .env.example .env
# Edit .env with your API keysDesarrollo de VS Code / DevContainer
Instalar VS Code con la extensión Contenedores Remotos
Abra la carpeta del proyecto en VS Code
Haga clic en "Reabrir en el contenedor" cuando se le solicite
El devcontainer se compilará y se abrirá con todas las dependencias instaladas
Uso del contenedor de desarrollo con Claude Desktop
Pasar el archivo de entorno a Docker Compose:
# Modern Docker Compose V2 syntax
docker compose --env-file .env up -dAgregue esto a su configuración de Claude Desktop:
{
"mcpServers": {
"image-recognition": {
"command": "docker",
"args": [
"exec",
"-i",
"mcp-image-recognition-dev",
"python",
"-m",
"image_recognition_server.server"
],
"env": {
"VISION_PROVIDER": "openai",
"OPENAI_API_KEY": "your-api-key",
"OPENAI_MODEL": "gpt-4o"
}
}
}
}Probar sus cambios localmente
Ejecute el servidor MCP en modo de desarrollo:
# Install the MCP Inspector if you haven't already
npm install -g @modelcontextprotocol/inspector
# Start the server with the Inspector
npx @modelcontextprotocol/inspector mcp-image-recognitionEl Inspector proporciona una interfaz web (normalmente en http://localhost:3000 ) donde puedes:
Envía solicitudes a tus herramientas
Ver registros de solicitud/respuesta
Depurar problemas con su implementación
Pruebe herramientas específicas:
Para
describe_image: Proporcione una imagen codificada en base64Para
describe_image_from_file: proporcione una ruta a un archivo de imagen localPara
describe_image_from_url: Proporcione una URL a una imagen
Integración con Claude Desktop para realizar pruebas
Modifique temporalmente la configuración de Claude Desktop para usar su versión de desarrollo:
{
"mcpServers": {
"image-recognition": {
"command": "python",
"args": [
"-m", "image_recognition_server.server"
],
"cwd": "/path/to/your/mcp-image-recognition",
"env": {
"VISION_PROVIDER": "openai",
"OPENAI_API_KEY": "your-api-key",
"OPENAI_MODEL": "gpt-4o"
}
}
}
}Reinicie Claude Desktop para aplicar los cambios
Prueba cargando imágenes o proporcionando URLs de imágenes en tus conversaciones
Ejecución de pruebas
Ejecutar todas las pruebas:
run.bat testEjecutar un conjunto de pruebas específico:
run.bat test server
run.bat test anthropic
run.bat test openaiSoporte de Docker
Construya la imagen de Docker:
docker build -t mcp-image-recognition .Ejecute el contenedor:
docker run -it --env-file .env mcp-image-recognitionLimitaciones de acceso a archivos de Docker
Al ejecutar el servidor MCP en Docker, la herramienta describe_image_from_file solo puede acceder a los archivos dentro del contenedor. De forma predeterminada, el contenedor no tiene acceso a los archivos del sistema host. Para habilitar el acceso a los archivos locales, debe asignar directorios explícitamente al configurar el servidor MCP.
Nota importante : Al usar Claude Desktop, Cursor u otras plataformas donde se suben imágenes a los chats, estas se almacenan en los servidores de Anthropic y no son accesibles directamente al servidor MCP a través de una ruta del sistema de archivos. En estos casos, debe:
Utilice la herramienta
describe_image(que funciona con imágenes codificadas en base64) para las imágenes cargadas directamente en el chatUtilice la nueva herramienta
describe_image_from_urlpara imágenes alojadas en líneaPara los archivos locales, asegúrese de que el directorio esté asignado correctamente al contenedor Docker
Asignación de directorios locales a Docker
Para darle al contenedor Docker acceso a carpetas específicas en su sistema, modifique la configuración de su servidor MCP para incluir la asignación de volúmenes:
{
"mcpServers": {
"image-recognition": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-v", "/path/on/host:/path/in/container",
"zudsniper/mcp-image-recognition:latest"
],
"env": {
"VISION_PROVIDER": "openai",
"OPENAI_API_KEY": "your-api-key",
"OPENAI_MODEL": "gpt-4o"
}
}
}
}Por ejemplo, para mapear su carpeta de Descargas:
Windows:
-v "C:\\Users\\YourName\\Downloads:/app/images"macOS/Linux:
-v "/Users/YourName/Downloads:/app/images"
Luego acceda a los archivos utilizando la ruta del contenedor: /app/images/your_image.jpg
Licencia
Licencia MIT: consulte el archivo LICENCIA para obtener más detalles.
Uso de Cloudflare Workers AI
Para utilizar Cloudflare Workers AI para el reconocimiento de imágenes:
Inicie sesión en el panel de Cloudflare y seleccione su cuenta.
Vaya a IA > IA de trabajadores .
Seleccione Usar API REST y cree un token de API con permisos de Workers AI.
Establezca lo siguiente en su archivo
.env:CLOUDFLARE_API_KEY: Su token de API de CloudflareCLOUDFLARE_ACCOUNT_ID: ID de su cuenta de CloudflareVISION_PROVIDER: Establecer encloudflareCLOUDFLARE_MODEL: Opcional, el valor predeterminado es@cf/llava-hf/llava-1.5-7b-hf
Uso con asistentes de IA
Una vez configurado, su asistente de IA (Claude, por ejemplo) puede analizar imágenes mediante:
Sube una imagen directamente en el chat
El asistente utilizará automáticamente el servidor MCP para analizar la imagen.
El asistente describirá la imagen en detalle basándose en la salida de la API de visión.
Ejemplo de mensaje después de cargar una imagen:
Please describe this image in detail.También puedes personalizar el mensaje según tus necesidades específicas:
What text appears in this image?o
Is there any safety concern in this image?Historial de versiones
1.2.1 (28/03/2025): Documentación reorganizada y flujo de trabajo de devcontainer mejorado
1.2.0 (28/03/2025): Se corrigió la obtención de imágenes de URL con encabezados httpx y del navegador, se agregó compatibilidad con devcontainer
1.1.0 (28/03/2025): Descripciones de herramientas mejoradas para una mejor selección, SDK de OpenAI actualizado a la última versión
1.0.1 (28/03/2025): Se agregó reconocimiento de imágenes basado en URL, se mejoró la documentación de Docker y se corrigieron las limitaciones del sistema de archivos.
1.0.0 (28/03/2025): Se agregó compatibilidad con Cloudflare Workers AI con el modelo llava-1.5-7b-hf, compatibilidad con Docker y compatibilidad con uvx.
0.1.2 (2025-02-20): Se mejoró el manejo de errores de OCR y se agregó una cobertura de prueba integral para la funcionalidad de OCR.
0.1.1 (19/02/2025): Se agregó compatibilidad con Tesseract OCR para la extracción de texto de imágenes (función opcional)
0.1.0 (19/02/2025): Versión inicial con compatibilidad con visión antrópica y OpenAI
Licencia
Licencia MIT: consulte el archivo LICENCIA para obtener más detalles.
Contribuyendo
¡Agradecemos sus contribuciones! No dude en enviar una solicitud de incorporación de cambios.
Lanzamiento de nuevas versiones
Para lanzar una nueva versión:
Actualizar la versión en
pyproject.tomlysetup.pyEnviar cambios a la rama
releaseLas acciones de GitHub harán lo siguiente automáticamente:
Ejecutar pruebas
Crear y enviar imágenes de Docker
Publicar en PyPI
Crear una versión de GitHub
Secretos de repositorio necesarios para CI/CD:
DOCKERHUB_USERNAME- Nombre de usuario de Docker HubDOCKERHUB_TOKEN- Token de acceso a Docker HubPYPI_API_TOKEN- Token API de PyPI
Available Tools
3 toolsdescribe_imageA
Describe an image from base64-encoded data. Use for images directly uploaded to chat.
Best for: Images uploaded to the current conversation where no public URL exists.
Not for: Local files on your computer or images with public URLs.
Args:
image: Base64-encoded image data
prompt: Optional prompt to guide the description
Returns:
str: Detailed description of the image
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | ||
| prompt | No | Please describe this image in detail. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively communicates the tool's behavior: it describes images, requires base64-encoded data, accepts an optional prompt for guidance, and returns a detailed description. However, it doesn't mention potential limitations like image size constraints, processing time, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by usage guidelines and parameter explanations. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description provides strong coverage of purpose, usage, and parameter semantics. It could be more complete by mentioning return format details or potential errors, but it adequately supports tool selection and invocation given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the schema's 0% coverage. It explains that 'image' expects 'Base64-encoded image data' and 'prompt' is 'Optional prompt to guide the description', clarifying the purpose of each parameter. The schema only provides titles and types without this semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Describe an image') and resource ('from base64-encoded data'), distinguishing it from sibling tools that handle files or URLs. It explicitly mentions the use case for 'images directly uploaded to chat'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use ('Best for: Images uploaded to the current conversation where no public URL exists') and when not to use ('Not for: Local files on your computer or images with public URLs'), with clear alternatives implied through sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_image_from_fileA
Describe an image from a local file path. Requires proper file system access.
Best for: Local files when the server has filesystem access to the path.
Limitations: When using Docker, requires volume mapping (-v flag) to access host files.
Not recommended for: Images uploaded to chat or images with public URLs.
Args:
filepath: Absolute path to the image file
prompt: Optional prompt to guide the description
Returns:
str: Detailed description of the image
| Name | Required | Description | Default |
|---|---|---|---|
| filepath | Yes | ||
| prompt | No | Please describe this image in detail. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it requires proper file system access, mentions Docker-specific constraints (volume mapping), and notes the optional prompt parameter. However, it lacks details on error handling, rate limits, or authentication needs, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by usage guidelines and parameter details. Every sentence adds value, with no redundant information, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, parameters, and behavioral constraints. However, it lacks details on the return value format beyond 'Detailed description of the image', and does not mention potential errors or side effects, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics beyond the schema by explaining that 'filepath' is an 'Absolute path to the image file' and 'prompt' is an 'Optional prompt to guide the description', which clarifies usage and constraints not evident from the schema alone. It covers both parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Describe an image') and resource ('from a local file path'), distinguishing it from sibling tools like describe_image and describe_image_from_url by specifying the local file source. It provides a verb+resource combination that is precise and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidelines with 'Best for:', 'Limitations:', and 'Not recommended for:' sections, clearly indicating when to use this tool (local files with filesystem access) versus alternatives (images uploaded to chat or with public URLs). It offers direct comparison to sibling tools by context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_image_from_urlA
Describe an image from a public URL. Most reliable method for web images.
Best for: Images with public URLs accessible from the internet.
Advantages: Works regardless of server deployment method (local/Docker).
Not for: Local files or images already uploaded to the current conversation.
Args:
url: Direct URL to the image (must be publicly accessible)
prompt: Optional prompt to guide the description
Returns:
str: Detailed description of the image
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Please describe this image in detail. | |
| url | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates key traits: the tool requires publicly accessible URLs, works reliably for web images, and handles deployment-agnostic access. However, it lacks details on rate limits, error handling, or authentication needs, which would elevate the score further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, usage guidelines, arguments, returns) and front-loaded key information. Every sentence adds value, such as distinguishing use cases and explaining parameters, with no redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete, covering purpose, usage, parameters, and return type. However, it could be enhanced with more behavioral details like response format or error cases, though the absence of an output schema makes this less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It clarifies that 'url' must be a 'Direct URL to the image (must be publicly accessible)' and 'prompt' is 'Optional prompt to guide the description', providing essential context not present in the schema's bare property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Describe an image') and resource ('from a public URL'), distinguishing it from sibling tools that handle local files or already-uploaded images. It explicitly contrasts with 'describe_image' and 'describe_image_from_file' by specifying the input source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Best for: Images with public URLs accessible from the internet') and when not to use it ('Not for: Local files or images already uploaded to the current conversation'). It also mentions advantages ('Works regardless of server deployment method') and implicitly references alternatives through sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clearly distinct purpose based on the image source: base64-encoded data, local file path, or public URL. The descriptions explicitly state what each tool is 'best for' and 'not for,' eliminating any ambiguity about when to use which tool.
All tool names follow a consistent verb_noun_from_source pattern (describe_image, describe_image_from_file, describe_image_from_url). This predictable naming makes it easy for an agent to understand the relationship between the tools and their specific use cases.
With 3 tools, this server is well-scoped for its purpose of image recognition across different input methods. Each tool earns its place by covering a distinct scenario (uploaded images, local files, web URLs), making the set complete without being bloated.
The tool surface comprehensively covers all common ways to provide an image for description: base64 data, local files, and public URLs. There are no obvious gaps, as these three methods handle most practical use cases an agent would encounter in image recognition tasks.
Maintenance
Related MCP Connectors
OCR, transcription, file extraction, and image generation for AI agents via MCP.
OCR and document understanding: extract text from images, then summarize or translate it.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Related MCP Servers
- AlicenseAqualityDmaintenanceEnables image analysis and understanding using Vision Language Models through OpenAI-compatible APIs. Supports analyzing images from URLs or local files with custom prompts.12MIT
- AlicenseAqualityCmaintenanceEnables image analysis using any OpenAI-compatible vision API, supporting URLs, local files, or base64 input with custom prompts.1MIT
- FlicenseNot gradedqualityCmaintenanceEnables image recognition using vision models via OpenAI-compatible APIs, supporting multiple platforms like OpenAI, DeepSeek, and Ollama.
- AlicenseAqualityBmaintenanceEnables image analysis, OCR, and text-to-image generation through OpenAI-compatible APIs. Supports local paths, URLs, or base64 images with configurable models and backup endpoints.355MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/mario-andreschak/mcp-image-recognition'
If you have feedback or need assistance with the MCP directory API, please join our Discord server