agent-eyes-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GEMINI_MODEL | No | Gemini model name. | gemini-2.5-flash |
| OLLAMA_MODEL | No | Ollama vision model name (must be pulled first). | qwen2.5vl |
| VISION_MODEL | No | OpenAI-compatible model name. | qwen-vl-max |
| GEMINI_API_KEY | No | Google Gemini API key (falls back to VISION_API_KEY). Required for gemini provider. | |
| VISION_API_KEY | No | API key for the OpenAI-compatible provider (also fallback for anthropic/gemini). Required for openai provider. | |
| ANTHROPIC_MODEL | No | Anthropic model name. | claude-haiku-4-5 |
| GEMINI_BASE_URL | No | Gemini generateContent base URL. | https://generativelanguage.googleapis.com |
| OLLAMA_BASE_URL | No | Local Ollama base URL. | http://localhost:11434 |
| VISION_BASE_URL | No | Base URL of an OpenAI-compatible /chat/completions endpoint. | https://dashscope.aliyuncs.com/compatible-mode/v1 |
| VISION_PROVIDER | No | Backend provider: openai | anthropic | gemini | ollama. Defaults to openai. | openai |
| ANTHROPIC_API_KEY | No | Anthropic API key (falls back to VISION_API_KEY). Required for anthropic provider. | |
| ANTHROPIC_BASE_URL | No | Anthropic Messages API base URL. | https://api.anthropic.com |
| AGENT_EYES_DISK_CACHE | No | Set to '1' to persist the description cache to disk. | |
| AGENT_EYES_ALLOWED_DIR | No | Root directory the file sandbox permits (relative paths still resolve against process.cwd()). | working directory |
| AGENT_EYES_DISK_CACHE_DIR | No | Disk cache directory (created lazily). | os.tmpdir()/agent-eyes-mcp/cache |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| describe_imageA | Analyze one or more images with a vision-language model (VLM) and return a text description. USE THIS TOOL when an image cannot be attached directly to the conversation but the model needs to see it: screenshots and screen recordings, error dialogs / crash screens, terminal or log output captured as images, charts, plots and diagrams, UI mockups and designs, photos, memes, or whenever a message references an image file path, http(s) URL, data: URI, or base64 string.Provide the image as: a local file path (relative paths resolve against the server working directory), an http(s) URL, a data: URI, or a raw base64 string. Pass a single string, or an array of strings to describe several images together (the reply contains one section per image).Optional parameters: question for a targeted question (overrides task), task preset (describe | ocr | ui | qa, default describe), detail level (low | high | auto, default high; forwarded only by the OpenAI-compatible provider). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The tool's purpose is clearly defined in its description.
The single tool name 'describe_image' follows a clear verb_noun pattern, which is consistent and predictable even with only one tool.
A one-tool server feels thin, but the tool description covers a broad range of image understanding tasks. It is borderline, not excessive.
The tool covers many use cases (OCR, UI analysis, question answering, multiple image formats), but lacks separate operations like listing supported models or image preprocessing. Minor gaps, but core functionality is solid.