j-can-see
Allows sending images to OpenAI vision models via the OpenAI Responses or Chat Completions API, returning text descriptions.
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., "@j-can-seeDescribe the screenshot in my clipboard."
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.
j-can-see
English | 中文文档
An MCP server that sends images (local file / URL / clipboard / latest screenshot) to a vision model and returns a text description.
Who is it for: AI coding clients like Claude Code / Codex whose primary model has no multimodal input (can't see images). Use the see_image tool to outsource vision.
The problem it solves
When the primary model doesn't support image input, Read-ing an image or pasting a screenshot into the conversation causes a direct 400 at the API layer and the whole turn crashes — the model never sees a "failure" event and can't recover on its own.
j-can-see turns vision into an ordinary text tool call: the model passes a path/URL and gets back a text description — usable by any text-only model.
Related MCP server: MCP Vision Server
Quick start
One-liner (recommended)
claude mcp add j-can-see -s user \
-e J_SEE_TOKEN='your-key' \
-e J_SEE_BASE_URL='https://your-proxy.example' \
-e J_SEE_MODEL='grok-4.5' \
-- npx -y j-can-see
-s userwrites the config to~/.claude.json(outside any git repo), so the key never leaks.
Manual configuration
Add this to the mcpServers section of ~/.claude.json:
"j-can-see": {
"command": "npx",
"args": ["-y", "j-can-see"],
"env": {
"J_SEE_TOKEN": "your vision model key",
"J_SEE_BASE_URL": "https://your-proxy.example",
"J_SEE_MODEL": "grok-4.5"
}
}Environment variables
Variable | Required | Default | Description |
| Yes | — | Vision model API key (not hardcoded — must be set explicitly) |
| Yes | — | Vision endpoint base URL (must match |
| Yes | — | Vision model name (must be set explicitly) |
| No |
| Upstream API spec (see below): |
| No |
| Reasoning effort (only honored by the |
| No |
| Max long-edge pixels for image compression |
| No |
| Max source file size in bytes; larger is rejected |
| No |
| Vision call timeout in milliseconds |
Missing required variables → crash on startup with a clear reason (fail fast).
J_SEE_MODELhas no default: use the vision model your endpoint actually supports. In testing,grok-4.5used fewer tokens than other candidates at equal description quality.
API specs (J_SEE_API_SPEC)
Three upstream specs, default responses:
Value | Endpoint | Use case |
|
| OpenAI Responses — native API for GPT-5 / Codex; aligns with the cc switch / Codex ecosystem |
|
| OpenAI Chat Completions — compatible with all OpenAI-compatible proxies (OpenRouter / LiteLLM / CLIProxyAPI / one-api, etc.) |
|
| Anthropic Messages — can call the Claude native API directly, no proxy needed |
Direct Claude (anthropic): call Anthropic directly without any OpenAI-compatible proxy:
claude mcp add j-can-see -s user \
-e J_SEE_API_SPEC='anthropic' \
-e J_SEE_TOKEN='sk-ant-...' \
-e J_SEE_BASE_URL='https://api.anthropic.com' \
-e J_SEE_MODEL='claude-sonnet-4-5-20250929' \
-- npx -y j-can-see
J_SEE_REASONINGis ignored underresponses/anthropic(onlyopenaihonors it).In practice, none of the three specs can fully turn off reasoning — the translation layer doesn't pass through effort, so a single vision call still burns a few hundred reasoning tokens (
responses≈ 500,openai≈ 900,anthropickeeps thinking off by default). Quality is unaffected; this is acceptable.Default
responses: if your proxy doesn't support/v1/responses(returns 404), the error message will suggest settingJ_SEE_API_SPEC=openai(no silent fallback — errors are reported as-is, and you decide explicitly to switch specs).
Tool: see_image
see_image({
source: string, // see table below
prompt?: string // omitted → "describe the image in detail, including text/UI/colors/layout"
}) → string // text description returned by the modelCLI
npx j-can-see --hook # print the PreToolUse hook script; save it locally and wire it up in Claude Code settingssource values
Value | Description |
Local path | Supports |
| Downloaded then described (content-type must be |
| Image in the system clipboard (mac / win only) |
| Most recent image in the screenshot directory |
Claude Code setup (MCP + Hook)
1. MCP server
See "Quick start" above; write to ~/.claude.json or a project-level .mcp.json.
2. PreToolUse Hook (recommended)
Without it, the model's instinct when it sees an image path is to Read it — which triggers that 400. The hook intercepts the request first and redirects to see_image:
Step 1: export the hook script
npx j-can-see --hook > ~/.claude/hooks/block-image-read.mjs
chmod +x ~/.claude/hooks/block-image-read.mjsStep 2: configure Claude Code
// ~/.claude/settings.json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Read",
"hooks": [
{
"type": "command",
"command": "node ~/.claude/hooks/block-image-read.mjs"
}
]
}
]
}
}The hook is deliberately conservative: it only intercepts
Readcalls on image file extensions. Multimodal models don'tReadimages (they consume image blocks directly), so the hook never misfires for them.
Codex setup
Codex has no PreToolUse interception, so rely on an AGENTS.md convention:
## Image recognition
This session's primary model has no multimodal capability; do not use view_image or read images directly.
To describe an image, call the MCP tool see_image({ source }).Less reliable than the hook, but it's all Codex supports for now.
Why these defaults (measured, not guessed)
Default | Evidence |
| The Responses endpoint (CLIProxyAPI + grok-4.6) works for vision in testing; reasoning tokens (≈500) are actually lower than Chat Completions (≈900), and it aligns with Codex / cc switch |
| Doesn't truly disable reasoning (the translation layer never forwards 0; ~900 reasoning tokens per vision call remain), but it's about twice as fast, saves ~28% tokens, and quality is unaffected |
Forced | Cloudflare bot protection returns 403 for default UAs (tested: urllib got 403) |
90s timeout | Shorter than Cloudflare Tunnel's 100s cap, so clients get a clear error before a 524 |
Sharing with others
The command for a friend is identical to yours — just replace J_SEE_TOKEN with a key issued for them.
claude mcp add j-can-see -s user \
-e J_SEE_TOKEN='friend-specific-key' \
-e J_SEE_BASE_URL='https://your-proxy.example' \
-e J_SEE_MODEL='grok-4.5' \
-- npx -y j-can-seeKey safety: one per person, never shared
CLIProxyAPI's api-keys is a flat array — all keys have equal permissions (no per-key model whitelist or quota). Never hand your main key to a friend.
Create a separate key per person on the server:
# /root/CLIProxyAPI/config.yaml
api-keys:
- sk-your-main-key # ← never give this to anyone
- sk-friend-A # ← friend A. If a key misbehaves, delete just that one
- sk-friend-B # ← friend BDo you need a gateway (quota / model whitelist)?
CLIProxyAPI currently has no per-key quota or model restrictions — a friend with a key can call every model on your backend (including expensive ones like video generation). If you trust your friends, no extra gateway is needed; if you need quotas/whitelists, add a thin gateway in front.
If the server side is CLIProxyAPI
No server-side changes needed — just point J_SEE_BASE_URL at it, since it already has HTTPS (Cloudflare Tunnel) + auth (api-keys) + OpenAI image compatibility.
Limitations
No Linux clipboard:
source: "clipboard"errors out clearly on Linux; use a file path instead (a declared boundary, not a silent fallback)Transparent PNGs are converted to JPEG (alpha becomes black); irrelevant for text screenshots
No retries, no fallback: vision failures are reported as-is; the caller decides
Development
npm install
npm test # vitest
npm run build # tsc → dist/Publishing
# 1. Bump version in package.json (e.g. 0.1.0 → 0.1.1)
# 2. Build
npm run build
# 3. Publish to npm (always use the official registry, even if a mirror is configured globally)
npm publish --registry=https://registry.npmjs.org/Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Tools
Related MCP Servers
- Alicense-qualityCmaintenanceAn MCP server that enables any LLM to describe images from file paths, URLs, or base64 data by forwarding them to a supported vision provider such as OpenAI, Anthropic, or local Ollama models.1,6459MIT
- Flicense-qualityBmaintenanceA versatile MCP server that adds vision capabilities (image analysis, OCR, image/video generation) to AI models lacking native vision, with support for multiple providers and automatic task routing.1
- FlicenseAqualityCmaintenanceMCP server enabling LLM clients without vision capability to process images by delegating to local Ollama vision models. Supports describing images, OCR, asking questions, and processing clipboard images.4
- FlicenseAqualityDmaintenanceMCP server for vision capabilities, enabling screenshot, camera, and image analysis using Ollama vision models.4
Related MCP Connectors
OCR, transcription, file extraction, and image generation for AI agents via MCP.
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for Google Veo AI video generation
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/PichurChill/j-can-see'
If you have feedback or need assistance with the MCP directory API, please join our Discord server