Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@kie-image-mcp generate an image of a futuristic city using google/nano-banana"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
KIE.ai の画像生成 MCP。KIE.ai 上の任意の画像生成モデル（google/nano-banana 系、GPT Image 2 系など）を model 引数または環境変数で指定できる。省略時の既定値のみ gpt-image-2-text-to-image / gpt-image-2-image-to-image。
kie_create_task / kie_check_task - 非同期の単体画像生成
kie_create_tasks / kie_check_tasks - 非同期の並列画像生成
kie_upload_file - ローカル参照画像を KIE.ai にアップロードし、image_input 用の URL を取得
Related MCP server: ImaginePro MCP Server
npm install
cp .env.example .env
# Set KIE_AI_API_KEY in .env
npm run buildAdd to .mcp.json:
{
"mcpServers": {
"kie-image": {
"type": "stdio",
"command": "node",
"args": ["/path/to/kie-image-mcp/dist/index.js"]
}
}
}Variable | Required | Description |
| Yes | KIE.ai API key |
| No |
|
| No |
|
| No | text-to-image 側の一括上書き。 |
| No | 既定解像度。 |
| No | Output directory (default: |
kie_create_task / kie_create_tasks は model 引数に KIE.ai の任意のモデル ID（例: google/nano-banana）を受け取る。省略時は以下で自動選択する。
入力 | 既定モデル |
|
|
|
|
モデルによって送信ペイロードを切り替える:
GPT Image 2 系（モデル ID が gpt-image-2 で始まる）: image_input を KIE.ai API の input_urls に変換して送る。text-to-image 系モデルに image_input を渡すとエラーにする。
それ以外（nano-banana 等）: image_input + output_format: png の形状で送る。
画像生成タスクのステータスを確認する。完了時は画像データを返し、save_to指定時はファイルにも保存する。pendingならしばらく待って再確認すること。
| Name | Required | Description | Default |
|---|---|---|---|
| save_to | No | 完了時に画像を保存するファイルパス（絶対パス、拡張子含む） | |
| task_id | Yes | 確認するタスクID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses return behavior (image data on completion), optional file saving, and polling advice. Lacks error handling or rate limit info but is mostly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no waste. Front-loaded with primary action, compact and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main behavior: check status, return image, optional save, retry hint. Missing details on return format (e.g., base64) and error handling. Adequate for simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context that save_to is used on completion and task_id is the identifier, but does not add significant detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of an image generation task and explains what happens on completion. It distinguishes from sibling tools which are plural or creation tools, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to wait and recheck if pending, which provides usage guidance. However, it does not specify when to use this tool over alternatives like kie_check_tasks or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
複数の画像生成タスクのステータスを並列で確認する。完了した画像はsave_dir指定時にファイル保存もする。
| Name | Required | Description | Default |
|---|---|---|---|
| save_dir | No | 完了した画像を保存するディレクトリの絶対パス。省略時は保存しない。 | |
| task_ids | Yes | 確認するタスクIDの配列（最大10件） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses parallel checking and optional file saving, but does not specify return value format, blocking behavior, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence covering both core function and optional behavior. Efficient and to the point, though could be structured slightly better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not explain return values (e.g., status objects). Missing guidance on how to interpret results, making it incomplete for a status-checking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% description coverage; description adds context that save_dir triggers file saving for completed images. Baseline 3 with minor added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks statuses of multiple image generation tasks in parallel, and optionally saves completed images. This distinguishes it from sibling 'kie_check_task' (singular).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for checking multiple tasks in parallel vs singular sibling, and mentions optional file saving. Lacks explicit when/why to use or exclude, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
KIE.aiで画像生成タスクを作成し、taskIdを即座に返す。モデルは引数または環境変数で切り替えられる。image_input がある場合は GPT Image 2 image-to-image 系モデルを既定で使う。
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | 使用モデル。省略時は image_input なしなら KIE_IMAGE_TEXT_TO_IMAGE_MODEL、image_input ありなら KIE_IMAGE_IMAGE_TO_IMAGE_MODEL を使う。既定値は gpt-image-2-text-to-image / gpt-image-2-image-to-image。 | |
| prompt | Yes | 画像生成プロンプト（英語推奨） | |
| resolution | No | 解像度（GPT Image 2: 1K / 2K / 4K） | 1K |
| image_input | No | 参照画像の配列（最大5件）。HTTP(S) URL または絶対ローカルパス（/Users/... など）を指定可能。ローカルパスは自動でKIE.aiのFile Upload APIにアップロードされ公開URLに変換される。キャラクター参照・スタイル参照に使用。 | |
| aspect_ratio | No | アスペクト比（デフォルト: 16:9） | 16:9 |
| negative_prompt | No | ネガティブプロンプト（避けたい要素） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It covers model selection, environment variable fallback, and automatic upload of local image paths. However, it omits that task creation is likely asynchronous and taskId is for polling, nor mentions any side effects, rate limits, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences in Japanese. First sentence states purpose, second explains model switching, third clarifies image_input behavior. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers creation and model behavior but is missing critical context about asynchronous execution (taskId used for polling), error handling, and output format. Given the existence of kie_check_task, this omission is notable. The description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage). The tool description adds extra value: explains model default logic based on image_input, and that image_input accepts URLs or local paths with auto-upload. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create image generation task') and immediate return of taskId. It explains model switching logic. However, it does not explicitly differentiate from the sibling tool 'kie_create_tasks' (plural) which likely creates multiple tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., kie_create_tasks for batch operations, kie_check_task for status). The description only states what the tool does, not usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
複数の画像生成タスクを並列で作成し、taskIdの配列を即座に返す。各タスクの model は個別指定でき、省略時は text-to-image / image-to-image を入力有無で切り替える。
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | 生成する画像タスクの配列（最大10件） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses parallel creation, immediate return of taskIds, and model auto-switching. However, it omits details on error handling, partial failures, or asynchronous processing, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the main action first and then a detail. Every sentence adds necessary information with no redundancy. It is well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description covers the core behavior well, but does not mention constraints like min/max tasks (1-10) or error scenarios. These are present in the schema but not in the description, so completeness is slightly diminished.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all nested properties. The description adds value by explaining the model auto-selection logic and default model names, which go beyond the schema's enum or defaults. Since schema coverage is high, a score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates multiple image generation tasks in parallel and returns an array of task IDs. The verb 'create' and resource 'tasks' are specified. It distinguishes from the sibling 'kie_create_task' by indicating batch processing, but does not explicitly contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch image generation tasks, but does not explicitly state when to use this tool versus the singular counterpart 'kie_create_task' or other siblings. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ローカル画像（絶対パス）をKIE.aiのFile Upload APIにアップロードし、公開downloadUrlを返す。通常はkie_create_taskのimage_inputにローカルパスを渡すだけで自動アップロードされるので、このツールは事前アップロード・URLのキャッシュ・複数タスクでの再利用時にのみ使う。保存期間は3日。
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | No | 保存ファイル名（省略時はランダム生成） | |
| file_path | Yes | アップロードするローカル画像の絶対パス | |
| upload_path | No | KIE.ai側の保存パス（先頭/末尾スラッシュなし） | images/user-uploads |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses that the tool returns a public download URL, has a 3-day storage period, and is a write operation. Missing details on authentication or rate limits, but sufficient for the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences, front-loaded with the core action and then providing contextual guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (public download URL) and storage duration, but does not specify exact output format or error conditions. Given no output schema, slightly more detail would be ideal, but it's still fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters. The tool description does not add per-parameter details, but the overall usage context is helpful. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a local image and returns a download URL. It also distinguishes from the sibling kie_create_task by noting that auto-upload is the norm, making this tool for explicit pre-upload or reuse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (pre-uploading, caching, reuse) and when not to (normally auto-uploaded by kie_create_task). Provides clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: creating single/multiple tasks, checking single/multiple tasks, and uploading files. No overlap or ambiguity.
All tools follow the consistent pattern 'kie_verb_noun' with singular/plural variants (check_task vs check_tasks, create_task vs create_tasks) and one upload_file.
Five tools cover the core workflow of image generation (create, check, upload) without being excessive or minimal. The count is well-scoped for the domain.
Covers creation, status checking, and file upload. Missing potential delete or cancel operations, but the set is functional for typical image generation tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create images and videos from prompts, with options for image mixing, reference images, and start/…
Generate images, videos, voiceovers, and captions from a chat prompt.
Image, video, music and text generation across 100+ models through one endpoint.
Generate reproducible image, video, and audio assets with leading models and your own provider keys.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nakia73/kie-image-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
