gigachat-image-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GIGACHAT_SCOPE | No | Access type (default: GIGACHAT_API_PERS). | |
| GIGACHAT_WAIT_MS | No | Time to wait for image generation before returning a job_id (default: 40000). | |
| IMAGE_OUTPUT_DIR | No | Directory where generated images are saved (default: ./images). | |
| GIGACHAT_API_BASE | No | GigaChat API base URL (default: https://gigachat.devices.sberbank.ru/api/v1). | |
| GIGACHAT_AUTH_KEY | No | GigaChat authorization key provided directly (instead of a key file). | |
| GIGACHAT_KEY_FILE | No | Path to the key.env file containing the GigaChat authorization key. | |
| GIGACHAT_LOG_FILE | No | Path to the call log file (default: gigachat-image.log next to index.js). | |
| GIGACHAT_TIMEOUT_MS | No | Timeout for a single request to Sber (default: 180000). | |
| NODE_EXTRA_CA_CERTS | Yes | Path to the Russian trusted CA certificate (certs/russian_trusted_ca.pem). |
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 |
|---|---|
| generate_imageA | Рисует изображение по текстовому описанию через GigaChat (модель Kandinsky), сохраняет JPG на диск и возвращает абсолютный путь к файлу. Промпт лучше писать на русском, подробно: объект, стиль, свет, ракурс, фон. Если картинка не готова за 40 с, инструмент вернёт job_id и путь будущего файла, а генерация продолжится в фоне — тогда проверяй её через check_image, а не повторным вызовом. ВАЖНО: каждый вызов — платный запрос к внешнему API Сбера, расходует пакет токенов пользователя. Перед КАЖДЫМ вызовом обязательно спроси пользователя: (1) разрешение, показав промпт (или список промптов, если картинок несколько), и (2) какую модель взять — Lite (GigaChat), Pro (GigaChat-Pro) или Max (GigaChat-Max). Модель не выбирай сам, даже если в прошлый раз пользователь выбрал какую-то, — спрашивай каждый раз. Рисует всегда Kandinsky; модель лишь разбирает промпт, а токены списываются из её пакета. Вызывай инструмент только после явного согласия и выбора модели. В ответе инструмент пишет, сколько токенов потрачено и сколько осталось, — обязательно передай эту строку пользователю. |
| check_imageA | Бесплатно (токены не тратит) показывает статус задачи generate_image: идёт, готово (с картинкой и расходом токенов) или ошибка с причиной. Без job_id — список последних задач и остаток токенов по пакетам Lite/Pro/Max. Разрешение пользователя не нужно. |
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 2 tools
generate_image creates an image (paid, requires user consent and model choice), while check_image only polls status/token balance (free, no consent needed). The descriptions explicitly cross-reference each other and even warn against using generate_image as a retry mechanism, so an agent cannot confuse them.
Both names follow a clean snake_case verb_noun pattern (generate_image, check_image) with the same noun, which accurately signals that the two tools act on the same resource.
Two tools is thin in absolute terms, but the server's scope is narrow (one image-generation backend with an async polling path), and both tools earn their place. Splitting the synchronous generate step from the free status check is a deliberate and justified design.
The surface covers the full async lifecycle: submit a generation, receive a job_id on timeout, and poll for completion, error, and token spend, plus a fallback listing of recent tasks. Minor gaps remain — no explicit cancel/delete for running jobs or saved files — but agents can work around these.