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

gigachat-image-mcp

by spolperim-lab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Статус генерации картинки

check_image
Read-only

Checks the status of an image-generation task—running, completed with image and token usage, or failed with reason—and lists recent tasks plus remaining Lite/Pro/Max tokens if no job ID is given.

Instructions

Бесплатно (токены не тратит) показывает статус задачи generate_image: идёт, готово (с картинкой и расходом токенов) или ошибка с причиной. Без job_id — список последних задач и остаток токенов по пакетам Lite/Pro/Max. Разрешение пользователя не нужно.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
job_idNoНомер задачи из ответа generate_image

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing that the call is free and consumes no tokens, that no user permission is required, and what each outcome returns (image plus token spend, or an error with a reason). These are exactly the behavioral facts an agent needs before calling.

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?

Three compact sentences, front-loaded with the free/no-token-cost fact and the outcome enumeration. Dense but every clause carries information; only slight compression could improve it.

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?

With no output schema, the description fully compensates by describing return values for each state and for the no-argument mode. 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% and the single parameter is already documented, but the description adds real meaning: job_id comes from the generate_image response, and its absence switches the tool into a listing/balance mode rather than being an error.

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?

States a specific verb and resource (shows the status of a generate_image task) and enumerates the three possible outcomes, which cleanly separates it from the generate_image sibling that creates images.

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

Usage Guidelines4/5

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

Explicitly covers both invocation modes: pass job_id to check a specific task, omit it to get the recent-task list plus remaining token balances. It does not spell out the alternative 'use generate_image to start a task', but the context makes the division of labor clear.

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