Computer Vision MCP Server
This Computer Vision MCP Server provides comprehensive image analysis capabilities through multiple tools and flexible backend support.
Core Functions:
Generate captions: Create concise (1-2 sentences) or detailed descriptions (2-6 sentences) via
caption_imageanddense_captiontoolsCreate alt text: Produce brief alternative text descriptions (≤20 words by default) via
alt_texttoolGenerate structured metadata: Extract comprehensive JSON metadata including alt text, captions, and additional details via
image_metadatatool withdoubleortripleprocessing modes
Flexible Configuration:
Multiple backends: Support for OpenRouter (Gemini models), local models (Hugging Face Transformers), and Ollama
Input options: Accept images from URLs or local file paths
Customization: Override default prompts, specify models per-call, use custom configuration files, and provide pre-existing captions to skip generation steps
MCP Integration: Runs as an MCP stdio server for seamless integration with clients like Claude Desktop
Provides image captioning capabilities using Google's Gemini 2.5 Flash model via OpenRouter API to generate concise descriptions of images from URLs or local files
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Computer Vision MCP Servercaption this image: https://example.com/sunset.jpg"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
cv-mcp
Minimal MCP server focused on computer vision: image recognition and metadata generation via OpenRouter (Gemini 2.5 family).
Goals
Keep it tiny and composable
Single tool: caption an image via URL or local file
No DB or app logic
Structure
src/cv_mcp/captioning/openrouter_client.py– image analysis clientsrc/cv_mcp/metadata/– prompts, JSON schema, and pipeline runnersrc/cv_mcp/mcp_server.py– MCP server exposing toolscli/caption_image.py– optional CLI to test captioning locally
Env vars
OPENROUTER_API_KEY
Dotenv
Put
OPENROUTER_API_KEYin a local.envfile (see.env.example).CLI scripts and the MCP server auto-load
.envif present.
Install
pip install -e .(orpip install .)
⚠️ Development Note: If you have the package installed via pip install, uninstall it before working with the local development version to avoid import conflicts. Use pip uninstall cv-mcp first, then run commands directly from the repo directory.
Run MCP server (stdio)
Console script:
cv-mcp-server(provides an MCP stdio server)Configure your MCP client to launch
cv-mcp-server.
MCP integration (Claude Desktop)
Add to Claude Desktop config (see their docs for the config location): { "mcpServers": { "cv-mcp": { "command": "cv-mcp-server", "env": { "OPENROUTER_API_KEY": "sk-or-..." } } } }
After saving, restart Claude Desktop and enable the tool.
Tools
caption_image: one-off caption (kept for compatibility)alt_text: short alt text (<= 20 words)dense_caption: detailed 2–6 sentence captionimage_metadata: structured JSON metadata with alt + caption. Params:mode:double(default) uses 2 calls: vision (alt+caption) + text-only (metadata).tripleuses vision for both steps.caption_override: supply your own dense caption; skips the vision caption step.
MCP tool reference
Server:
cv-mcp(stdio)caption_image(image_url|file_path, prompt?, backend?, local_model_id?) -> stringalt_text(image_url|file_path, max_words?) -> stringdense_caption(image_url|file_path) -> stringimage_metadata(image_url|file_path, caption_override?, config_path?) -> { alt_text, caption, metadata }
Examples
MCP call (OpenRouter): {"image_url": "https://example.com/image.jpg"}
MCP call (local): {"backend": "local", "file_path": "./image.jpg"}
Quick test (CLI)
URL:
python cli/caption_image.py --image-url https://example.com/img.jpgFile:
python cli/caption_image.py --file-path ./image.png
Metadata pipeline (CLI)
Double (default):
python cli/image_metadata.py --image-url https://example.com/img.jpg --mode doubleLocal alt+caption (still requires OpenRouter for metadata):
python cli/image_metadata.py --image-url https://example.com/img.jpg --mode double --ac-backend local
Triple (vision metadata):
python cli/image_metadata.py --image-url https://example.com/img.jpg --mode tripleFully local (no OpenRouter required):
python cli/image_metadata.py --image-url https://example.com/img.jpg --mode triple --ac-backend local --meta-vision-backend local
With existing caption (skips the caption step):
python cli/image_metadata.py --image-url https://example.com/img.jpg --caption-override "<dense caption>" --mode double
Custom model config (JSON with
caption_model,metadata_text_model,metadata_vision_model):python cli/image_metadata.py --image-url https://example.com/img.jpg --config-path ./my_models.json --mode double
Schema & vocab
JSON schema (lean):
src/cv_mcp/metadata/schema.jsonControlled vocab (non-binding reference):
src/cv_mcp/metadata/vocab.json
Global config
Root file:
cv_mcp.config.json(auto-detected from project root / CWD)Env override: set
CV_MCP_CONFIG=/path/to/config.jsonKeys (renamed for clarity):
caption_model: vision model for alt+caption (OpenRouter)metadata_text_model: text model for metadata (double mode)metadata_vision_model: vision model for metadata (triple mode)caption_backend:openrouter(default) orlocalfor alt/dense/AC stepsmetadata_vision_backend:openrouter(default) orlocalfor triple modelocal_vlm_id: default local VLM (e.g.Qwen/Qwen2.5-VL-7B-Instruct)Backwards-compat: legacy keys (
ac_model,meta_text_model,meta_vision_model,ac_backend,meta_vision_backend,local_model_id) are still accepted.
Packaged defaults still live at
src/cv_mcp/metadata/config.jsonand are used if no root config is found.You can still provide a custom config file per-call via
--config-pathor theconfig_pathtool param.
Local backends (optional)
Install optional deps:
pip install .[local]Global default: set
"caption_backend": "local"(and optionally"metadata_vision_backend": "local") incv_mcp.config.jsonUse with MCP: pass
backend: "local"in the tool params (overrides global)Use with CLI: add
--backend localand optionally--local-model-id Qwen/Qwen2-VL-2B-Instruct(overrides global)Requires a locally available model (default:
Qwen/Qwen2-VL-2B-Instructvia HF cache)Or run without transformers using Ollama (no Python ML deps):
Install and run Ollama; pull a vision model (e.g.,
ollama pull qwen2.5-vl)Use backend
ollamaand set models in the config (e.g.,caption_model: "qwen2.5-vl")CLI example (triple, fully local):
python cli/image_metadata.py --image-url https://... --mode triple --caption-backend ollama --metadata-vision-backend ollama --config-path ./configs/triple_ollama_qwen.json
Configure host with
--ollama-host http://localhost:11434if not default
Per-call overrides (CLI)
Metadata CLI now supports per-call backend overrides without editing global config:
--caption-backend local|openrouter|ollama(legacy:--ac-backend)--metadata-vision-backend local|openrouter|ollama(legacy:--meta-vision-backend)--local-vlm-id Qwen/Qwen2.5-VL-7B-Instruct(legacy:--local-model-id)--ollama-host http://localhost:11434
Justfile tasks
A
Justfileprovides quick test scenarios. Use URL-only inputs, e.g.just double_flash https://example.com/img.jpg.Scenarios included:
double_flash: Gemini 2.5 Flash for both stepsdouble_pro: Gemini 2.5 Pro for both stepsdouble_mixed_pro_text: Flash for vision alt+caption, Pro for text metadata (recommended mix for JSON reliability)triple_flash/triple_pro: Flash/Pro for both vision stepsdouble_qwen_local <url> <qwen_id>: Local Qwen 2.5 VL for vision step, Pro for text metadatatriple_qwen_local <url> <qwen_id>: Fully local Qwen 2.5 VL for both vision stepsConvenience (no extra args):
double_qwen2b_local <url>/triple_qwen2b_local <url>double_qwen7b_local <url>/triple_qwen7b_local <url>
Recommendation for mixed double
Put Gemini 2.5 Pro on the text metadata step and Flash on the vision alt+caption step. The metadata step benefits from better structured-JSON compliance and reasoning, while Flash keeps latency/cost down for the vision caption.
OpenRouter key requirements:
Double mode always requires
OPENROUTER_API_KEY(text LLM for metadata).Triple mode requires
OPENROUTER_API_KEYunless both--ac-backend localand--meta-vision-backend localare set.
Examples
MCP tool (local):
{"backend": "local", "file_path": "./image.jpg"}CLI (local):
python cli/caption_image.py --file-path ./image.jpg --backend local
Troubleshooting
401/403 from OpenRouter: ensure
OPENROUTER_API_KEYis set and valid.Model selection: prefer
cv_mcp.config.jsonat project root; or pass--config-path.Large images: remote images are downloaded and sent as base64; ensure the URL is accessible.
Local backend: install optional deps
pip install .[local]and ensure model is present/cached.
Changelog
See
docs/CHANGELOG.mdfor notable changes and release notes.
Available Tools
4 toolsalt_textD
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | ||
| image_url | No | ||
| max_words | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
caption_imageD
| Name | Required | Description | Default |
|---|---|---|---|
| backend | No | ||
| file_path | No | ||
| image_url | No | ||
| local_model_id | No | ||
| prompt | No | Write a concise, vivid caption for this image. Describe key subjects, scene, and mood in 1-2 sentences. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
dense_captionD
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | ||
| image_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
image_metadataD
| Name | Required | Description | Default |
|---|---|---|---|
| caption_override | No | ||
| config_path | No | ||
| file_path | No | ||
| image_url | No | ||
| mode | No | double |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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: alt_text generates descriptive text for accessibility, caption_image creates a general caption, dense_caption provides detailed region-specific captions, and image_metadata extracts technical data. There is no overlap in functionality, making tool selection unambiguous.
All tool names follow a consistent snake_case pattern with descriptive noun-based naming (alt_text, caption_image, dense_caption, image_metadata). The naming is uniform and predictable across all four tools.
With 4 tools, the count is reasonable for a computer vision server, covering key image analysis tasks. It is slightly lean but well-scoped, as each tool addresses a distinct aspect of image processing without redundancy.
The tools cover descriptive and metadata extraction tasks well, but there are notable gaps in core computer vision operations like object detection, image classification, or segmentation. The surface is incomplete for a full computer vision workflow, though the provided tools are coherent within their subset.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Analyze images from multiple angles to extract detailed insights or quick summaries. Describe visu…
Analyze images and videos with Gemini to get fast, reliable visual insights. Handle content from U…
Generate images with your own ChatGPT subscription (Plus, Pro or Team), without spending API credits
Image/video analysis: NSFW detection, object detection, thumbnails
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables image processing and analysis using Google's Gemini 2.5 Flash model. Supports local files, URLs, and Base64 images with streaming responses and automatic output saving.1MIT
- 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
- AlicenseBqualityDmaintenanceEnables vision capabilities for any AI model by routing image analysis requests through OpenRouter's vision models. It provides tools to analyze images from URLs, local file paths, or base64 data.210120MIT
- AlicenseAqualityCmaintenanceEnables image analysis using any OpenAI-compatible vision API, supporting URLs, local files, or base64 input with custom prompts.1MIT
Appeared in Searches
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/samhains/cv-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server