Skip to main content
Glama
enesjakozh
mario-andreschak

MCP Image Recognition Server

by mario-andreschak
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

MCP图像识别服务器

一款 MCP 服务器，使用 Anthropic、OpenAI 和 Cloudflare Workers AI 视觉 API 提供图像识别功能。版本 1.2.1。

MCP图像识别

作者

该项目最初由@mario-andreschak创建。谢谢！
它目前由@zudsniper维护。

Related MCP server: Image Parse MCP

特征

  • 使用 Anthropic Claude Vision、OpenAI GPT-4 Vision 或 Cloudflare Workers AI llava-1.5-7b-hf 进行图像描述

  • 轻松与 Claude Desktop、Cursor 和其他 MCP 兼容客户端集成

  • 支持 Docker 部署

  • 支持 uvx 安装

  • 支持多种图像格式（JPEG、PNG、GIF、WebP）

  • 可配置的主要和后备提供商

  • Base64 和基于文件的图像输入支持

  • 使用 Tesseract OCR 进行可选文本提取

要求

  • Python 3.8 或更高版本

  • Tesseract OCR（可选）- 文本提取功能所需

    • Windows：从UB-Mannheim/tesseract下载并安装

    • Linux： sudo apt-get install tesseract-ocr

    • macOS： brew install tesseract

安装

选项 1：使用 uvx（推荐用于 Claude Desktop 和 Cursor）

  1. 安装uv包管理器：

pip install uv

  1. 使用 uvx 安装包：

uvx install mcp-image-recognition

  1. 按照配置部分所述创建并配置环境文件

选项 2：使用 Docker

docker pull zudsniper/mcp-image-recognition:latest

# Create a .env file first, then run:
docker run -it --env-file .env zudsniper/mcp-image-recognition

选项 3：从源头

  1. 克隆存储库：

git clone https://github.com/zudsniper/mcp-image-recognition.git
cd mcp-image-recognition

  1. 创建并配置您的环境文件：

cp .env.example .env
# Edit .env with your API keys and preferences

  1. 构建项目：

pip install -e .

一体化

Claude 桌面集成

  1. 转到Claude >设置>开发人员>编辑配置> claude_desktop_config.json

  2. 添加带有内联环境变量的配置：

{
    "mcpServers": {
        "image-recognition": {
            "command": "uvx",
            "args": [
                "mcp-image-recognition"
            ],
            "env": {
                "VISION_PROVIDER": "openai",
                "OPENAI_API_KEY": "your-api-key",
                "OPENAI_MODEL": "gpt-4o"
            }
        }
    }
}

光标集成

转到Cursor Settings > MCP并粘贴环境变量：

VISION_PROVIDER=openai OPENAI_API_KEY=your-api-key OPENAI_MODEL=gpt-4o uvx mcp-image-recognition

Docker 集成

选项 1：使用 DockerHub 镜像

将其添加到具有内联环境的 Claude Desktop 配置中：

{
    "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"
            }
        }
    }
}

对于 Cloudflare 配置：

"env": {
    "VISION_PROVIDER": "cloudflare",
    "CLOUDFLARE_API_KEY": "your-api-key",
    "CLOUDFLARE_ACCOUNT_ID": "your-account-id"
}

用法

直接运行服务器

如果使用 pip/uvx 安装：

mcp-image-recognition

从源目录：

python -m image_recognition_server.server

使用 Docker：

docker run -it --env-file .env zudsniper/mcp-image-recognition

使用 MCP Inspector 以开发模式启动：

npx @modelcontextprotocol/inspector mcp-image-recognition

可用工具

  1. describe_image

    • 目的：分析直接上传到聊天中的图像

    • 输入：Base64编码的图像数据

    • 输出：图像的详细描述

    • 最适合：直接上传到 Claude、Cursor 或其他聊天界面的图像

  2. describe_image_from_file

    • 目的：处理来自文件系统的本地图像文件

    • 输入：图像文件的路径

    • 输出：图像的详细描述

    • 最适合：具有文件系统访问的本地开发

    • 注意：在 Docker 中运行时，需要卷映射（请参阅 Docker 文件访问部分）

  3. describe_image_from_url

    • 目的：分析来自网页 URL 的图像，无需手动下载

    • 输入：可公开访问图像的 URL

    • 输出：图像的详细描述

    • 最适合：Web 图像、屏幕截图或任何具有公共 URL 的内容

    • 注意：使用类似浏览器的标头来避免速率限制

环境配置

  • ANTHROPIC_API_KEY ：您的 Anthropic API 密钥。

  • OPENAI_API_KEY ：您的 OpenAI API 密钥。

  • CLOUDFLARE_API_KEY ：您的 Cloudflare API 密钥。

  • CLOUDFLARE_ACCOUNT_ID ：您的 Cloudflare 帐户 ID。

  • VISION_PROVIDER ：主要视觉提供商（ anthropic 、 openai或cloudflare ）。

  • FALLBACK_PROVIDER ：可选的后备提供程序。

  • LOG_LEVEL ：日志级别（DEBUG、INFO、WARNING、ERROR）。

  • ENABLE_OCR ：启用 Tesseract OCR 文本提取（ true或false ）。

  • TESSERACT_CMD ：Tesseract 可执行文件的可选自定义路径。

  • OPENAI_MODEL ：OpenAI 模型（默认值： gpt-4o-mini ）。其他模型可以使用 OpenRouter 格式（例如anthropic/claude-3.5-sonnet:beta ）。

  • OPENAI_BASE_URL ：OpenAI API 的可选自定义基本 URL。对于 OpenRouter，请设置为https://openrouter.ai/api/v1 。

  • OPENAI_TIMEOUT ：OpenAI API 的可选自定义超时（以秒为单位）。

  • CLOUDFLARE_MODEL ：Cloudflare Workers AI 模型（默认值： @cf/llava-hf/llava-1.5-7b-hf ）。

  • CLOUDFLARE_MAX_TOKENS ：要生成的最大令牌数（默认值： 512 ）。

  • CLOUDFLARE_TIMEOUT ：Cloudflare API 请求的超时时间（秒）（默认值： 60 ）。

使用 OpenRouter

OpenRouter 允许您使用 OpenAI API 格式访问各种模型。要使用 OpenRouter，请按照以下步骤操作：

  1. 从 OpenRouter 获取 OpenAI API 密钥。

  2. 将.env文件中的OPENAI_API_KEY设置为您的 OpenRouter API 密钥。

  3. 将OPENAI_BASE_URL设置为https://openrouter.ai/api/v1 。

  4. 使用 OpenRouter 格式将OPENAI_MODEL设置为所需模型（例如， anthropic/claude-3.5-sonnet:beta ）。

  5. 将VISION_PROVIDER设置为openai 。

默认模型

  • 人择： claude-3.5-sonnet-beta

  • OpenAI： gpt-4o-mini

  • Cloudflare Workers AI： @cf/llava-hf/llava-1.5-7b-hf

  • OpenRouter：在OPENAI_MODEL中使用anthropic/claude-3.5-sonnet:beta格式。

发展

开发设置指南

设置开发环境

  1. 克隆存储库：

git clone https://github.com/zudsniper/mcp-image-recognition.git
cd mcp-image-recognition

  1. 使用 uv 设置（推荐）：

# 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]"

使用 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

  1. 配置环境：

cp .env.example .env
# Edit .env with your API keys

VS Code / DevContainer 开发

  1. 使用远程容器扩展安装 VS Code

  2. 在 VS Code 中打开项目文件夹

  3. 出现提示时，单击“在容器中重新打开”

  4. devcontainer 将构建并打开，并安装所有依赖项

使用 Claude Desktop 开发容器

  1. 将环境文件传递给docker compose：

# Modern Docker Compose V2 syntax
docker compose --env-file .env up -d

  1. 将其添加到您的 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"
            }
        }
    }
}

在本地测试您的更改

  1. 以开发模式运行 MCP 服务器：

# 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-recognition

  1. Inspector 提供了一个 Web 界面（通常位于http://localhost:3000 ），您可以在其中执行以下操作：

    • 向您的工具发送请求

    • 查看请求/响应日志

    • 调试实施过程中的问题

  2. 测试特定工具：

    • 对于describe_image ：提供 base64 编码的图像

    • 对于describe_image_from_file ：提供本地图像文件的路径

    • 对于describe_image_from_url ：提供图像的 URL

与 Claude Desktop 集成进行测试

  1. 临时修改您的 Claude Desktop 配置以使用您的开发版本：

{
    "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"
            }
        }
    }
}

  1. 重新启动 Claude Desktop 以应用更改

  2. 通过在对话中上传图片或提供图片 URL 进行测试

运行测试

运行所有测试：

run.bat test

运行特定的测试套件：

run.bat test server
run.bat test anthropic
run.bat test openai

Docker 支持

构建 Docker 镜像：

docker build -t mcp-image-recognition .

运行容器：

docker run -it --env-file .env mcp-image-recognition

Docker 文件访问限制

在 Docker 中运行 MCP 服务器时， describe_image_from_file工具只能访问容器内的文件。默认情况下，容器无法访问主机系统上的文件。要启用对本地文件的访问，必须在配置 MCP 服务器时明确映射目录。

重要提示：使用 Claude Desktop、Cursor 或其他需要上传图片到聊天的平台时，这些图片会存储在 Anthropic 的服务器上，MCP 服务器无法通过文件系统路径直接访问。在这种情况下，您应该：

  1. 使用describe_image工具（适用于 base64 编码的图像）将图像直接上传到聊天室

  2. 使用新的describe_image_from_url工具来处理在线托管的图像

  3. 对于本地文件，确保目录正确映射到 Docker 容器

将本地目录映射到 Docker

要让 Docker 容器访问系统上的特定文件夹，请修改 MCP 服务器配置以包含卷映射：

{
    "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"
            }
        }
    }
}

例如，映射您的下载文件夹：

  • Windows： -v "C:\\Users\\YourName\\Downloads:/app/images"

  • macOS/Linux： -v "/Users/YourName/Downloads:/app/images"

然后使用容器路径访问文件： /app/images/your_image.jpg

执照

MIT 许可证 - 详情请参阅 LICENSE 文件。

使用 Cloudflare Workers AI

要使用 Cloudflare Workers AI 进行图像识别：

  1. 登录Cloudflare 仪表板并选择您的帐户。

  2. 转到AI >工人 AI 。

  3. 选择使用 REST API并创建具有 Workers AI 权限的 API 令牌。

  4. 在您的.env文件中设置以下内容：

    • CLOUDFLARE_API_KEY ：您的 Cloudflare API 令牌

    • CLOUDFLARE_ACCOUNT_ID ：您的 Cloudflare 帐户 ID

    • VISION_PROVIDER ：设置为cloudflare

    • CLOUDFLARE_MODEL ：可选，默认为@cf/llava-hf/llava-1.5-7b-hf

与人工智能助手一起使用

配置完成后，您的 AI 助手（例如 Claude）可以通过以下方式分析图像：

  1. 直接在聊天中上传图片

  2. 助手将自动使用 MCP 服务器分析图像

  3. 助手将根据视觉 API 的输出详细描述图像

上传图片后的示例提示：

Please describe this image in detail.

您还可以根据特定需求自定义提示：

What text appears in this image?

或者

Is there any safety concern in this image?

发布历史

  • 1.2.1 (2025-03-28)：重新组织文档并改进 devcontainer 工作流程

  • 1.2.0 (2025-03-28)：修复使用 httpx 和浏览器标头获取 URL 图像的问题，添加了 devcontainer 支持

  • 1.1.0 （2025-03-28）：增强工具描述以便更好地选择，将 OpenAI SDK 更新至最新版本

  • 1.0.1 (2025-03-28)：添加基于 URL 的图像识别、改进 Docker 文档并修复文件系统限制

  • 1.0.0 (2025-03-28)：添加了 Cloudflare Workers AI 对 llava-1.5-7b-hf 模型的支持、Docker 支持和 uvx 兼容性

  • 0.1.2 (2025-02-20)：改进了 OCR 错误处理并增加了 OCR 功能的全面测试覆盖率

  • 0.1.1 (2025-02-19)：添加了 Tesseract OCR 支持，用于从图像中提取文本（可选功能）

  • 0.1.0 （2025-02-19）：初始版本，支持 Anthropic 和 OpenAI 视觉

执照

MIT 许可证 - 详情请参阅 LICENSE 文件。

贡献

欢迎贡献代码！欢迎提交 Pull 请求。

发布新版本

要发布新版本：

  1. 更新pyproject.toml和setup.py中的版本

  2. 将更改推送到release分支

  3. GitHub Actions 将自动：

    • 运行测试

    • 构建并推送 Docker 镜像

    • 发布到 PyPI

    • 创建 GitHub 版本

CI/CD 所需的存储库机密：

  • DOCKERHUB_USERNAME - Docker Hub 用户名

  • DOCKERHUB_TOKEN - Docker Hub 访问令牌

  • PYPI_API_TOKEN - PyPI API 令牌

Available Tools

3 tools
describe_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
ParametersJSON Schema
NameRequiredDescriptionDefault
imageYes
promptNoPlease describe this image in detail.

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
filepathYes
promptNoPlease describe this image in detail.

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden 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.

Conciseness5/5

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.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault
promptNoPlease describe this image in detail.
urlYes

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden 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.

Conciseness5/5

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.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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

TDQS

A4.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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

ActivityInactive
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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