Skip to main content
Glama
WormAlien

opencode-openai-vision-mcp

by WormAlien

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 OpenCode

This 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

  1. Node.js >= 18

  2. A vision-capable model reachable via an OpenAI-compatible /chat/completions endpoint (OmniRoute, LiteLLM, OpenAI, etc.).

  3. The opencode-vision plugin (AGPL-3.0) — this is what intercepts the pasted image inside OpenCode and calls the local_vision tool. 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 install

Quick 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 error

Configure 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 local makes its tool resolve to local_vision, which matches the default imageAnalysisTool of 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

VISION_BASE_URL

http://localhost:20128/v1

OpenAI-compatible base URL (must end in /v1).

VISION_API_KEY

(empty)

Bearer token for the endpoint. Omitted if empty.

VISION_MODEL

gpt-4o

Vision model name, or a gateway alias.

VISION_MAX_TOKENS

1024

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), optional question.

  • 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

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 tool
visionA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesAbsolute path to the image file on disk.
questionNoOptional. What to look for or ask about the image. Defaults to a full description.

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev1.0.0
    • First observedvision

TDQS

A3.9/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools.

Naming Consistency3/5

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.

Tool Count3/5

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.

Completeness3/5

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

ActivityStale
ResponsivenessNo issues

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

Related MCP Servers

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/WormAlien/OpenCode-vision-OmniRoute'

If you have feedback or need assistance with the MCP directory API, please join our Discord server