Skip to main content
Glama
Sign In
gigachat-image-mcp

gigachat-image-mcp

by spolperim-lab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Сгенерировать картинку (GigaChat / Kandinsky)

generate_image

Creates an image from a text prompt via GigaChat (Kandinsky) and saves it as a JPG, returning the absolute file path. Use check_image to poll jobs still running in the background.

Instructions

Рисует изображение по текстовому описанию через GigaChat (модель Kandinsky), сохраняет JPG на диск и возвращает абсолютный путь к файлу. Промпт лучше писать на русском, подробно: объект, стиль, свет, ракурс, фон. Если картинка не готова за 40 с, инструмент вернёт job_id и путь будущего файла, а генерация продолжится в фоне — тогда проверяй её через check_image, а не повторным вызовом. ВАЖНО: каждый вызов — платный запрос к внешнему API Сбера, расходует пакет токенов пользователя. Перед КАЖДЫМ вызовом обязательно спроси пользователя: (1) разрешение, показав промпт (или список промптов, если картинок несколько), и (2) какую модель взять — Lite (GigaChat), Pro (GigaChat-Pro) или Max (GigaChat-Max). Модель не выбирай сам, даже если в прошлый раз пользователь выбрал какую-то, — спрашивай каждый раз. Рисует всегда Kandinsky; модель лишь разбирает промпт, а токены списываются из её пакета. Вызывай инструмент только после явного согласия и выбора модели. В ответе инструмент пишет, сколько токенов потрачено и сколько осталось, — обязательно передай эту строку пользователю.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>",
      "model": "<model>"
    },
    "name": "generate_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
modelYesМодель, которую выбрал пользователь: GigaChat (Lite), GigaChat-Pro (Pro) или GigaChat-Max (Max). Спроси перед каждым вызовом
styleNoСистемный промпт для стиля, например «Ты — художник-минималист, рисуешь плоские векторные иллюстрации»
promptYesЧто нарисовать
filenameNoИмя файла без расширения (по умолчанию — дата и время)
output_dirNoПапка для сохранения (по умолчанию IMAGE_OUTPUT_DIR)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: every call is a paid external Sber API request that consumes the user's token quota, generation may complete in the background with a job_id plus a future file path, and the response includes a token-spend/remaining line the agent must relay to the user. The annotations only supply the readOnly/openWorld/idempotent profile; the cost and async-timeout behavior is unique value added here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what the tool does, then timeout behavior, then the cost/consent rules — a sensible order for the most consequential facts. It is quite long and slightly duplicative (the 'never pick the model yourself / only call after explicit consent' rule is restated twice), which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description fully specifies the returns: absolute file path, job_id plus future path on timeout, and the token-usage line. For a paid, asynchronous, side-effecting generation tool, the consent protocol, timeout handling and output shape are all covered; nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline 3 is already justified, but the description adds real meaning: it advises writing the prompt in Russian with object, style, light, angle and background details, and clarifies that the 'model' parameter only affects prompt interpretation while Kandinsky always does the drawing. That non-obvious semantics of 'model' is the kind of information the schema cannot carry.

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?

Opens with a concrete verb+resource: draws an image from a text description via GigaChat/Kandinsky, saves a JPG to disk, and returns the absolute file path. It also names the sibling check_image and explains the role split (Kandinsky draws, the GigaChat model only parses the prompt), so an agent can distinguish it from check_image immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to call (only after explicit user consent and model selection) and when not to re-call: on a 40s timeout, poll with check_image instead of invoking again. It even defines the pre-call checklist (show prompt, ask model every single time) and names the three model choices, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools