Сервер Model Context Protocol (MCP) для генерации и редактирования изображений с помощью ИИ на базе модели Google Nano Banana через API AceDataCloud.
Создавайте и редактируйте изображения с помощью ИИ прямо из Claude, VS Code или любого другого клиента, совместимого с MCP.
Генерация изображений - Создание высококачественных изображений по текстовым запросам
Редактирование изображений - Изменение существующих изображений или
Edit or combine images using AI based on a text prompt.
This allows you to modify existing images or combine multiple images together.
Perfect for virtual try-on, product placement, image enhancement, and more.
Use this when:
- You want to combine multiple images (e.g., person + clothing)
- You want to modify an existing image
- You need virtual try-on (putting clothes on a person)
- You want to place products in different scenes
- You need to change attributes (materials, colors, styles)
Common use cases:
- Portrait replacement: Try different clothing on same person
- Product scene composition: Place products in realistic environments
- Attribute replacement: Change materials, colors, or variants
- Poster editing: Rapidly change styles or themes
- 2D to 3D conversion: Convert images to 3D product mockups
- Image restoration: Restore old or damaged photos
Returns:
Task ID, trace ID, and edited image URL.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Description of the edit to perform. Describe how the images should be combined or modified. Example: 'let this person wear this T-shirt', 'place this product in a modern kitchen scene' | |
| image_urls | Yes | List of image URLs to edit. Can be HTTP/HTTPS URLs (publicly accessible) or Base64-encoded images (data:image/png;base64,...). When combining multiple images, describe their relationship in the prompt. | |
| callback_url | No | Optional webhook URL to receive the result asynchronously. The API will POST the result to this URL when complete. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool performs AI-based image editing/combination, supports multiple image inputs, handles both URLs and Base64 data (implied from schema), and returns a Task ID, trace ID, and image URL. It also mentions asynchronous processing via callback_url. However, it lacks details on rate limits, error conditions, or specific permissions required.
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 well-structured with clear sections (purpose, usage guidelines, common use cases, returns) and front-loaded key information. However, it includes some redundancy (e.g., 'Common use cases' partially overlaps with 'Use this when:') and could be more concise by merging similar points, though all sentences contribute meaningful context.
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 tool's complexity (AI-based image editing with multiple inputs), no annotations, and an output schema (implied by 'Returns' section), the description is highly complete. It covers purpose, usage scenarios, behavioral aspects, and return values, providing sufficient context for an agent to understand when and how to invoke the tool effectively without relying on structured fields.
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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by briefly mentioning 'text prompt' and 'multiple images' in the opening, but does not provide additional syntax, format, or usage details for parameters. The baseline score of 3 is appropriate as the schema does the heavy lifting.
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's purpose with specific verbs ('edit or combine images using AI based on a text prompt') and distinguishes it from sibling tools like 'nanobanana_generate_image' by focusing on modifying existing images rather than generating new ones from scratch. It explicitly mentions the resource ('images') and the AI-driven mechanism.
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 provides explicit guidance on when to use this tool through a dedicated 'Use this when:' section listing five specific scenarios (e.g., combining multiple images, modifying an image, virtual try-on). It also distinguishes from alternatives by implying this is for editing existing images, unlike 'nanobanana_generate_image' for generation from scratch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an AI image from a text prompt using Google's Nano Banana model.
This creates high-quality images from detailed text descriptions. The more
descriptive your prompt, the better the results.
Use this when:
- You want to generate a new image from scratch
- You have a detailed description of the desired image
- You need photorealistic or artistic image generation
Prompt writing tips:
- Include: Main subject + Atmosphere + Lighting + Camera/Lens + Quality keywords
- Example: "Urban career woman, backlit sunlight, film grain, orange-gold tones, hopeful dawn"
Returns:
Task ID, trace ID, and generated image URL.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Description of the image to generate. Be descriptive about subject, atmosphere, lighting, camera/lens, and quality. Example: 'A photorealistic close-up portrait of an elderly Japanese ceramicist with deep wrinkles and a warm smile, soft golden hour light, 85mm portrait lens, bokeh background' | |
| callback_url | No | Optional webhook URL to receive the result asynchronously. The API will POST the result to this URL when complete. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a generative operation ('creates high-quality images'), mentions quality dependencies ('more descriptive your prompt, the better the results'), and specifies the return format ('Task ID, trace ID, and generated image URL'). However, it doesn't cover potential limitations like rate limits, error conditions, or authentication needs, leaving some gaps.
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 well-structured and front-loaded, starting with the core purpose, followed by usage guidelines, tips, and return details. Each sentence earns its place by adding actionable information (e.g., prompt examples, when-to-use criteria) without redundancy. It's appropriately sized for a tool with two parameters and clear functionality.
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 tool's complexity (generative AI image creation), the description is complete enough. It covers purpose, usage, behavioral aspects, and return values, and with an output schema present, it doesn't need to explain return values in detail. The combination of description, schema (100% coverage), and output schema provides a comprehensive context for the agent.
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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds value by reinforcing the prompt's importance ('The more descriptive your prompt, the better the results') and providing detailed prompt writing tips with an example, which enhances understanding beyond the schema's technical descriptions. It doesn't add new parameter details but improves contextual usage.
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 specific action ('Generate an AI image from a text prompt') and resource ('using Google's Nano Banana model'), distinguishing it from sibling tools like nanobanana_edit_image (which edits existing images) and nanobanana_get_task (which retrieves task status). It explicitly mentions creating high-quality images from detailed descriptions, establishing its unique purpose.
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 provides explicit usage scenarios with a bulleted list ('Use this when:') that includes when to use this tool (e.g., 'generate a new image from scratch') and implicitly when not to use it (e.g., for editing existing images, which is handled by nanobanana_edit_image). It also offers prompt writing tips, further guiding effective usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the status and result of an image generation or edit task.
Use this to check if a generation/edit is complete and retrieve the resulting
image URLs and metadata.
Use this when:
- You want to check if an image generation has completed
- You need to retrieve image URLs from a previous generation
- You want to get the full details of a generated/edited image
Returns:
Task status and image information including URLs and prompts.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | The task ID returned from a generation or edit request. This is the 'task_id' field from any nanobanana_generate_image or nanobanana_edit_image tool response. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool queries task status and retrieves results, which implies it's a read-only operation without side effects. However, it lacks details on potential errors (e.g., invalid task IDs), rate limits, or authentication needs, leaving behavioral gaps for an agent.
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 well-structured and front-loaded, starting with a clear purpose statement followed by usage guidelines and return details. Each sentence adds essential information without redundancy, making it efficient and easy to parse.
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 tool's moderate complexity (single parameter, read-only query), the description is mostly complete. It covers purpose, usage, and returns, and an output schema exists, so return values need not be detailed. However, it lacks error handling or behavioral constraints, slightly reducing completeness.
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 has 100% description coverage, so the baseline is 3. The description adds value by explaining the parameter's origin ('task_id' from generation/edit responses) and its role in retrieving task details, enhancing understanding beyond the schema's technical definition.
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's purpose with specific verbs ('Query the status and result') and resources ('image generation or edit task'), distinguishing it from siblings like nanobanana_generate_image (which creates tasks) and nanobanana_get_tasks_batch (which handles multiple tasks). It explicitly mentions retrieving image URLs and metadata, which sets it apart from creation tools.
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 provides explicit usage scenarios in a bulleted list, including when to use it (e.g., to check completion status or retrieve image URLs) and implies when not to use it (e.g., not for creating new tasks, which is handled by nanobanana_generate_image or nanobanana_edit_image). This offers clear guidance on context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query multiple image generation/edit tasks at once.
Efficiently check the status of multiple tasks in a single request.
More efficient than calling nanobanana_get_task multiple times.
Use this when:
- You have multiple pending generations to check
- You want to get status of several images at once
- You're tracking a batch of generations
Returns:
Status and image information for all queried tasks.
| Name | Required | Description | Default |
|---|---|---|---|
| task_ids | Yes | List of task IDs to query. Allows querying multiple tasks at once. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool as a query/check operation, implying it's read-only and non-destructive, and mentions efficiency benefits. However, it lacks details on potential rate limits, error handling, or authentication needs. The description adds some context but doesn't fully cover behavioral traits beyond the basic purpose.
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 front-loaded with the core purpose, followed by efficiency comparison, usage guidelines, and return information. Each sentence adds value without redundancy, and the structure is clear and well-organized. It's appropriately sized for the tool's complexity, with no wasted 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?
Given the tool's low complexity (single parameter, no nested objects), high schema coverage, and the presence of an output schema (which handles return values), the description is complete enough. It covers purpose, usage guidelines, efficiency context, and return summary, addressing all necessary aspects without needing to duplicate schema information.
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 has 100% description coverage, with the parameter 'task_ids' well-documented as 'List of task IDs to query. Allows querying multiple tasks at once.' The description doesn't add any additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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's purpose as 'Query multiple image generation/edit tasks at once' and 'Efficiently check the status of multiple tasks in a single request,' specifying the verb (query/check), resource (tasks), and scope (multiple/batch). It explicitly distinguishes from the sibling tool nanobanana_get_task by noting it's 'More efficient than calling nanobanana_get_task multiple times,' providing clear differentiation.
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 includes explicit usage guidelines with a 'Use this when:' section listing three specific scenarios (e.g., 'You have multiple pending generations to check'), and it names the alternative tool nanobanana_get_task, providing clear when-to-use and when-not-to-use guidance. This directly helps the agent choose between this tool and its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0nanobanana_edit_imagenanobanana_generate_imagenanobanana_get_tasknanobanana_get_tasks_batchScored across 4 tools
Each tool has a clearly distinct purpose with no overlap: generate_image creates new images from prompts, edit_image modifies or combines existing images, get_task retrieves single task results, and get_tasks_batch retrieves multiple task results. The descriptions reinforce these distinct roles, making tool selection unambiguous.
All tools follow a consistent snake_case pattern with the prefix 'nanobanana_' followed by a clear verb_noun combination (edit_image, generate_image, get_task, get_tasks_batch). The naming convention is perfectly uniform across all four tools, making them predictable and easy to understand.
Four tools is well-scoped for an image generation/editing server, covering core operations: generation, editing, and status retrieval (both single and batch). Each tool earns its place without redundancy, providing a complete yet manageable surface for the domain.
The tool set covers the essential lifecycle of image tasks: create (generate_image), modify (edit_image), and retrieve results (get_task and get_tasks_batch). A minor gap exists in lacking explicit deletion or management tools for tasks, but agents can work around this as the core workflows are fully supported.
Generate AI images and videos from any compatible MCP client.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
Generate images, video, audio and short films with 140+ AI models from any MCP client.
