analyze-image-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VISION_MODEL | Yes | ID vision-модели | |
| VISION_API_KEY | Yes | API-ключ провайдера | |
| VISION_BASE_URL | Yes | Базовый URL OpenAI-compatible API, например https://your-provider.com/v1 |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| analyze_imageA | Analyzes an image using a dedicated vision model and returns a detailed text description. Use this whenever the user attaches or references an image and the active model cannot see images itself. Accepts a local file path, file:// URI, http(s) URL, or data: URL. |
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
There is only one tool, so there is no possibility of confusing it with another. Its purpose—analyze an image and return a text description—is unambiguous, and the description clearly scopes when to use it.
The single tool name 'analyze_image' follows a clean verb_noun snake_case convention. With no other names to conflict with, consistency is trivially perfect.
The server's scope is narrowly a single capability—image analysis—so one tool is largely justified and each tool earns its place. It sits below the typical 3-15 range, and optional additions like batch analysis or multi-image comparison could be argued for, keeping it just short of ideal.
The tool covers the core lifecycle for its purpose: it accepts local paths, file URIs, http(s) URLs, and data URLs, so most image-referencing workflows are reachable. Minor gaps exist around batch/multiple-image handling and structured output options, but no dead ends for the primary use case.