opencode-openai-vision-mcp
Provides vision capabilities by sending images to OpenAI-compatible vision models for analysis and description.
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., "@opencode-openai-vision-mcpWhat does this screenshot show?"
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.
opencode-openai-vision-mcp
A tiny MCP server that gives OpenCode (and any other MCP client) working image/vision support through any OpenAI-compatible endpoint — for example an OmniRoute or LiteLLM gateway, or OpenAI itself.
It reads an image file from disk, sends it to a vision-capable model as an
image_url content block, and returns the model's text description.
Why this exists
OpenCode currently cannot send image attachments to vision models served through a
custom OpenAI-compatible provider (@ai-sdk/openai-compatible). The attachment is
dropped before it reaches the model, and the assistant replies with something like:
this model does not support image input
This is an OpenCode adapter bug, tracked upstream in
anomalyco/opencode#20802
(fix PRs #26826 /
#21627 were not merged at the time
of writing). The underlying model and gateway are usually fine — a direct
/chat/completions call with image_url works; only OpenCode's conversion is broken.
This project is a workaround: instead of relying on OpenCode's native image path, it routes images through an MCP tool that you fully control.
Related MCP server: image-recognition-mcp
How it works
OpenCode (you paste a screenshot)
└─ opencode-vision plugin intercepts the image inside OpenCode,
(separate project, see below) saves it to a temp file, and rewrites the
message to "call local_vision with this path"
└─ local_vision (THIS server) reads the file, base64-encodes it, and POSTs
it as image_url to an OpenAI-compatible endpoint
└─ your gateway/model e.g. OmniRoute -> any vision model
returns a text description back to OpenCodeThis is a describe-then-reason approach: a vision model looks at the image and returns text; your main model works from that text. It is not native multimodality, but it restores the "paste a screenshot and ask" workflow.
Prerequisites
Node.js >= 18
A vision-capable model reachable via an OpenAI-compatible
/chat/completionsendpoint (OmniRoute, LiteLLM, OpenAI, etc.).The opencode-vision plugin (AGPL-3.0) — this is what intercepts the pasted image inside OpenCode and calls the
local_visiontool. This MCP server is the tool it calls. You need both.
Install
git clone https://github.com/WormAlien/opencode-openai-vision-mcp.git
cd opencode-openai-vision-mcp
npm installQuick self-test (optional) — point it at your gateway and it should print a color word:
VISION_BASE_URL=http://localhost:20128/v1 \
VISION_API_KEY=your-key \
VISION_MODEL=your-vision-model \
node server.js
# then drive it with any MCP client, or just confirm it starts without errorConfigure OpenCode
Add the MCP server to your opencode.json (see opencode.example.json):
{
"mcp": {
"local": {
"type": "local",
"command": ["node", "/absolute/path/to/opencode-openai-vision-mcp/server.js"],
"enabled": true,
"environment": {
"VISION_BASE_URL": "http://localhost:20128/v1",
"VISION_API_KEY": "YOUR_GATEWAY_API_KEY",
"VISION_MODEL": "your-vision-model-or-alias"
}
}
}
}Naming the server
localmakes its tool resolve tolocal_vision, which matches the defaultimageAnalysisToolof the opencode-vision plugin — so no extra wiring needed.
Then enable the plugin for your models via opencode-vision.json
(see opencode-vision.example.json):
{
"models": ["your-provider/*"],
"imageAnalysisTool": "local_vision"
}Restart OpenCode, select a model under that provider, paste an image, and ask away.
Environment variables
Variable | Default | Description |
|
| OpenAI-compatible base URL (must end in |
| (empty) | Bearer token for the endpoint. Omitted if empty. |
|
| Vision model name, or a gateway alias. |
|
| Max tokens for the description. |
Tip: point VISION_MODEL at a gateway alias (e.g. a vision alias in OmniRoute).
Then you can swap the real model in your gateway dashboard without editing any config.
The vision tool
Input:
path(absolute path to a PNG/JPEG/WebP/GIF), optionalquestion.Output: a text description (transcribes visible text by default).
Handles both plain JSON and SSE/streamed responses from the endpoint.
Notes / limitations
The image must be readable on the same machine the server runs on (it reads from the local filesystem path the plugin saved).
Quality depends entirely on the vision model you point it at.
Once OpenCode merges native image support for openai-compatible providers (#20802), you may not need this.
Credits
opencode-vision (AGPL-3.0) — the OpenCode plugin that intercepts images and calls the MCP tool. A separate project; not bundled here.
Model Context Protocol and its TypeScript SDK.
License
MIT — see LICENSE. (This applies to this MCP server only; the opencode-vision plugin has its own AGPL-3.0 license.)
Available Tools
1 toolvisionA
Analyze a local image file using a vision-capable model and return a text description. Use this whenever the user shares an image/screenshot. Pass the absolute file path.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the image file on disk. | |
| question | No | Optional. What to look for or ask about the image. Defaults to a full description. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It explains that the tool uses a 'vision-capable model' and returns text, but it does not disclose potential failure modes (e.g., unsupported file formats), permissions needed, or whether the operation reads but does not modify data. This leaves gaps for an AI agent.
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 extremely concise: two sentences that immediately convey the tool's purpose, usage context, and a key requirement (absolute path). No redundant information is present.
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 simplicity (2 parameters, no output schema), the description covers essential aspects: what the tool does, when to use it, and a key parameter requirement. It could elaborate on return format or limitations, but it is largely sufficient for a straightforward tool.
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 coverage is 100%, so the description's contribution is limited. It reiterates that the path should be an 'absolute file path,' which is already in the schema. The description does not add new semantics beyond the schema, meeting the baseline for high coverage.
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 tool's purpose: 'Analyze a local image file using a vision-capable model and return a text description.' It includes a specific use case ('whenever the user shares an image/screenshot'), distinguishing it from potential alternatives even though no siblings are listed.
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 advises when to use this tool: 'Use this whenever the user shares an image/screenshot.' While it does not provide when-not or alternatives, the guidance is clear and context-appropriate given no siblings.
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. Dates show when Glama detected each change.
1 tool update
v1.0.0- First observed
vision
TDQS
Only one tool exists, so there is no possibility of confusion between tools.
The single tool is named 'vision', which is a noun rather than a verb_noun pattern. While there is no inconsistency, the naming lacks a clear action-oriented convention.
With only one tool, the server feels minimal. For a focused purpose like image analysis it may be acceptable, but it is on the low end of the scale.
The tool covers the stated purpose of analyzing images, but there are no additional capabilities like OCR or object detection, limiting completeness for broader vision tasks.
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
AI-powered image processing via GPU. Remove backgrounds and upscale images (2x/4x) directly from any MCP client. OAuth 2.1 authenticated, returns processed images inline with download links. Free credits on signup at maskr.io.
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables text-only LLMs to analyze images by routing them to an OpenAI-compatible vision backend, supporting local files, URLs, and data URLs.26MIT
- AlicenseAqualityBmaintenanceGives vision-less LLMs the ability to recognize clipboard screenshots and images by proxying to an OpenAI-compatible vision model.1242MIT
- FlicenseAqualityBmaintenanceGives any MCP client (OpenCode, Claude Code, Claude Desktop, Cursor, etc.) the ability to process images by automatically converting them to text descriptions using a vision model, so that text-only LLMs can handle image-based queries.2-
- FlicenseNot gradedqualityBmaintenanceEnables pure text LLMs to understand images by acting as a proxy to vision models via OpenAI-compatible APIs. Supports local files, URLs, and base64 inputs for image analysis.-
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/WormAlien/OpenCode-vision-OmniRoute'
If you have feedback or need assistance with the MCP directory API, please join our Discord server