Skip to main content
Glama
runapi-ai

Nano Banana MCP Server

by runapi-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Why This Package?

@runapi.ai/nano-banana-mcp is a focused Model Context Protocol server for the Nano Banana model line on RunAPI. It gives MCP-compatible assistants direct access to 2 endpoints and 5 model variants without loading the full RunAPI catalog.

Use this per-model server when an agent should stay scoped to Nano Banana. Use @runapi.ai/mcp when one assistant should discover every RunAPI model line.

Related MCP server: GPT Image MCP Server

Install

Add it to Claude Code:

claude mcp add nano-banana -s user -- npx -y @runapi.ai/nano-banana-mcp

Use project scope when the server should be shared with a repository:

claude mcp add nano-banana -s project -- npx -y @runapi.ai/nano-banana-mcp

Codex, Cursor, Windsurf, VS Code, Roo Code, and other MCP hosts can use the same stdio command:

{
  "mcpServers": {
    "nano-banana": {
      "command": "npx",
      "args": ["-y", "@runapi.ai/nano-banana-mcp"]
    }
  }
}

check_pricing works before sign-in. For task creation and status polling, ask your assistant to call the login tool. It opens a browser login and saves credentials to ~/.config/runapi/config.json, the same file used by runapi login. Headless and CI hosts can still set RUNAPI_API_KEY before starting the MCP host.

Ready-made examples are in examples/ for Claude, Cursor, Windsurf, VS Code, and Roo Code.

Tools

Tool

Auth

Purpose

edit_image

Yes

Create a Nano Banana edit image task and optionally wait for a terminal status. Returns the task id, status, and output URLs.

text_to_image

Yes

Create a Nano Banana text to image task and optionally wait for a terminal status. Returns the task id, status, and output URLs.

get_task

Yes

Fetch the current status and latest payload for an existing task.

check_pricing

No

Look up current pricing for a Nano Banana model and endpoint.

Models

Nano Banana covers 5 model variants across 2 endpoints. Each tool accepts the models listed for it:

Tool

Models

edit_image

nano-banana-2-lite, nano-banana-edit

text_to_image

nano-banana, nano-banana-2, nano-banana-2-lite, nano-banana-pro

Model availability can change between releases. Use check_pricing or the Nano Banana model page for the current catalog view.

Agent Prompts

Ask your assistant in natural language; it can inspect pricing, create the task, and return the task id plus output URLs.

Create a task

Run a Nano Banana edit image task with RunAPI.

The assistant can call check_pricing, then edit_image, and return the task id, status, and output URLs.

Submit without waiting

Create the task but don't wait for it to finish.

The assistant calls the create tool with wait: false and returns the task id. Check on it later with get_task.

Check pricing before creating

Check current Nano Banana pricing, then create the task if it matches my request.

The assistant calls check_pricing and can link to the Nano Banana model page for the canonical catalog entry.

Configuration

The server resolves auth in this order:

  1. RUNAPI_API_KEY environment variable, useful for headless and CI hosts

  2. ~/.config/runapi/config.json, created by the MCP login tool or runapi login

  3. No key, which still allows check_pricing

The config file is normally managed by login. A pre-provisioned headless config can use:

{
  "apiKey": "your_runapi_key"
}

Do not commit real API keys.

Links

Resource

URL

Nano Banana model page

https://runapi.ai/models/nano-banana

npm package

@runapi.ai/nano-banana-mcp

GitHub repository

runapi-ai/nano-banana-mcp

RunAPI MCP overview

runapi.ai/mcp

RunAPI docs

runapi.ai/docs

License

Licensed under the Apache License, Version 2.0.

Available Tools

5 tools
check_pricingB

Look up RunAPI pricing for the nano-banana model line.

ParametersJSON Schema
NameRequiredDescriptionDefault
modelNoModel slug. Defaults to the line's primary model.
actionNoEndpoint name. Defaults to the endpoint that offers the model.

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. 'Look up' implies a non-mutating read, which is helpful, but the description does not confirm read-only behavior, describe the shape of the pricing result, or mention any caching/rate-limit behavior. For a simple lookup this is acceptable but thin.

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

Conciseness5/5

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

A single front-loaded sentence with no filler. The resource and scope are stated immediately with zero redundancy.

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

Completeness3/5

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

For a two-optional-parameter read tool this is close, but with no output schema the description should say what pricing information is returned (per-endpoint cost, units, currency). That gap leaves the agent unsure what to expect from the call.

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

Parameters3/5

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

Schema description coverage is 100% and both parameters are documented in the schema, including the defaults and the endpoint enum. The description adds no syntax, format, or defaulting detail beyond what the schema already provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('look up'), resource ('pricing'), and scope ('nano-banana model line'), which is enough for an agent to distinguish it from the sibling tools (login, edit_image, text_to_image, get_task), none of which concern pricing. It is clear but does not explicitly contrast itself with an alternative.

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

Usage Guidelines2/5

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

There is no statement of when to call this versus alternatives, no preconditions, and no exclusions. Usage is only implied by the tool's name and the resource it targets.

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

edit_imageC

Create a Nano Banana task on RunAPI (edit image). Returns a task id, status, and output URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
waitNoPoll until the task reaches a terminal status.
modelNoRunAPI model slug for this model line.
promptNoDeclared type: string.
timeout_msNo
aspect_ratioNoDeclared type: string. Known values: "1:1", "1:4", "1:8", "2:3", "3:2", "3:4", "4:1", "4:3", "4:5", "5:4", "8:1", "9:16", "16:9", "21:9", "auto".
callback_urlNoDeclared type: string.
output_formatNoDeclared type: string. Known values: "png", "jpeg".
poll_interval_msNo
source_image_urlsYesDeclared type: array.

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden, yet it discloses only the return shape (task id, status, output URLs). It never explains the asynchronous task model, what the wait/poll_interval_ms/timeout_ms parameters do to execution, whether callback_url is needed, or any cost/auth implications.

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?

Two short sentences with no filler, and the core action plus return contract are front-loaded. It is efficient, though the brevity is part of the reason behavioral context is thin.

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

Completeness2/5

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

For a 9-parameter asynchronous mutation tool with no annotations and no output schema, the description is too sparse. It names the return fields but omits polling/timeout semantics, callback behavior, and how source_image_urls drives the edit, leaving the agent under-informed.

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

Parameters3/5

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

Schema description coverage is 78%, so most fields are documented in the schema, and the description adds nothing beyond them. Notably prompt, source_image_urls, timeout_ms and poll_interval_ms carry no meaningful schema description either, leaving several of the 9 parameters opaque in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource ("Create a ... task") and names the operation (edit image), which separates it from text_to_image by implying source-image input. The model name "Nano Banana" and platform "RunAPI" are niche identifiers, but the action is unambiguous.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of the sibling text_to_image, which is the obvious alternative for image generation without a source image. An agent must infer the choice from the parenthetical "(edit image)" alone.

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

get_taskA

Fetch the current status and latest result payload for a nano-banana task.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAsynchronous endpoint the task was created on.
task_idYesTask id returned when the task was created.

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It implies a repeatable read ('current status') and indicates a result payload is returned, which is useful, but it omits what happens for pending/failed tasks, whether results are retained or expire, and whether polling is required.

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

Conciseness5/5

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

A single front-loaded sentence with zero waste; the verb and the returned data are both stated immediately.

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

Completeness4/5

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

There is no output schema, so the description correctly names what is returned ('current status and latest result payload'). For a simple two-parameter poll tool this is nearly sufficient, with only task-state and failure behavior left unstated.

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

Parameters3/5

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

Schema description coverage is 100%, so both task_id and the action enum are already documented in the schema. The description adds no additional meaning about how task_id or action correlate with task creation, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Fetch the current status and latest result payload for a nano-banana task.' This clearly distinguishes it from the async creation siblings (edit_image, text_to_image), though it never explicitly names itself as their polling counterpart.

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

Usage Guidelines3/5

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

Usage is only implied: fetching 'current status' suggests polling a task created via edit_image/text_to_image, but the description never states when to call it, how often, or what to do instead. No alternatives or exclusions are named.

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

loginA

Authenticate RunAPI by opening a browser PKCE login flow and saving the API key to ~/.config/runapi/config.json.

ParametersJSON Schema
NameRequiredDescriptionDefault
forceNoRe-run browser login when the current credential comes from the local config file.

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses the interactive browser flow and the file write side effect (config.json). However, it does not mention that it may overwrite existing credentials or that it could block waiting for user input, though these are implied.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the action ('Authenticate RunAPI') and provides necessary details without extraneous information.

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

Completeness4/5

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

For a simple login tool with one optional parameter and no output schema, the description covers the core purpose and side effect. It lacks an explicit statement that this is a prerequisite for other tools, but that is implied.

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

Parameters3/5

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

Schema description coverage is 100% (the only parameter 'force' has a description). The tool description adds no additional meaning about parameters beyond the schema, so the baseline of 3 applies.

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?

The description clearly states the tool's purpose with a specific verb ('Authenticate'), target resource ('RunAPI'), method ('browser PKCE login flow'), and side effect (saving to config.json). It is distinct from sibling tools, none of which relate to authentication.

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

Usage Guidelines3/5

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

The description implies usage (to authenticate RunAPI) but does not explicitly say when to run it (e.g., before other RunAPI tools) or when to use the 'force' parameter. Since there are no alternative auth tools among siblings, 'vs alternatives' is not applicable.

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

text_to_imageC

Create a Nano Banana task on RunAPI (text to image). Returns a task id, status, and output URLs.

ParametersJSON Schema
NameRequiredDescriptionDefault
waitNoPoll until the task reaches a terminal status.
modelNoRunAPI model slug for this model line.
promptNoDeclared type: string.
timeout_msNo
aspect_ratioNoDeclared type: string. Known values: "1:1", "9:16", "16:9", "3:4", "4:3", "3:2", "2:3", "5:4", "4:5", "21:9", "auto", "1:4", "1:8", "4:1", "8:1".
callback_urlNoDeclared type: string.
output_formatNoDeclared type: string. Known values: "png", "jpeg", "jpg".
poll_interval_msNo
output_resolutionNoDeclared type: string.
reference_image_urlsNoDeclared type: array.

TDQS

C2.9/5.0
Behavior2/5

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 return values (task id, status, output URLs), which is useful, but says nothing about cost/credits (despite a check_pricing sibling), auth requirements, or what the wait/poll behavior means in practice.

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?

Two short sentences, front-loaded with the action and returning the output contract. Nothing is wasted, though the vendor jargon costs a little clarity.

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

Completeness2/5

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

For a 10-parameter generation tool with zero required params, no annotations, and no output schema, the description is thin. It omits cost implications, the meaning of wait/timeout/poll_interval, and callback_url semantics that an agent needs to invoke it well.

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

Parameters3/5

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

Schema coverage is 80%, so the schema already documents most parameters; the description adds no syntax or format detail. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Create a Nano Banana task") and disambiguates with "(text to image)", which separates it from the sibling edit_image. The jargon "Nano Banana task on RunAPI" is vendor-specific but the parenthetical makes the intent clear.

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

Usage Guidelines2/5

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

No when-to-use guidance and no routing to alternatives: it never says to use edit_image for modifying an existing image or get_task to poll results. With a close sibling (edit_image) present, the absence of any differentiation is a real gap.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.2.0
    • Changedcheck_pricing2 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • removedInput schema / properties / model / enum
        Removed value: -[
-  "nano-banana-2-lite",
-  "nano-banana-edit",
-  "nano-banana",
-  "nano-banana-2",
-  "nano-banana-pro"
-]
    • Changededit_image13 fields changed
      • addedInput schema / additionalProperties
        Added value: +{}
      • removedInput schema / properties / aspect_ratio / anyOf
        Removed value: -[
-  {
-    "const": "1:1",
-    "type": "string"
-  },
-  {
-    "const": "1:4",
-    "type": "string"
-  },
-  {
-    "const": "1:8",
-    "type": "string"
-  },
-  {
-    "const": "2:3",
-    "type": "string"
-  },
-  {
-    "const": "3:2",
-    "type": "string"
-  },
-  {
-    "const": "3:4",
-    "type": "string"
-  },
-  {
-    "const": "4:1",
-    "type": "string"
-  },
-  {
-    "const": "4:3",
-    "type": "string"
-  },
-  {
-    "const": "4:5",
-    "type": "string"
-  },
-  {
-    "const": "5:4",
-    "type": "string"
-  },
-  {
-    "const": "8:1",
-    "type": "string"
-  },
-  {
-    "const": "9:16",
-    "type": "string"
-  },
-  {
-    "const": "16:9",
-    "type": "string"
-  },
-  {
-    "const": "21:9",
-    "type": "string"
-  },
-  {
-    "const": "auto",
-    "type": "string"
-  }
-]
      • addedInput schema / properties / aspect_ratio / description
        Added value: +"Declared type: string. Known values: \"1:1\", \"1:4\", \"1:8\", \"2:3\", \"3:2\", \"3:4\", \"4:1\", \"4:3\", \"4:5\", \"5:4\", \"8:1\", \"9:16\", \"16:9\", \"21:9\", \"auto\"."
      • addedInput schema / properties / aspect_ratio / type
        Added value: +"string"
      • addedInput schema / properties / callback_url / description
        Added value: +"Declared type: string."
      • removedInput schema / properties / model / enum
        Removed value: -[
-  "nano-banana-2-lite",
-  "nano-banana-edit"
-]
      • removedInput schema / properties / output_format / anyOf
        Removed value: -[
-  {
-    "const": "png",
-    "type": "string"
-  },
-  {
-    "const": "jpeg",
-    "type": "string"
-  }
-]
      • addedInput schema / properties / output_format / description
        Added value: +"Declared type: string. Known values: \"png\", \"jpeg\"."
      • addedInput schema / properties / output_format / type
        Added value: +"string"
      • addedInput schema / properties / prompt / description
        Added value: +"Declared type: string."
      • removedInput schema / properties / prompt / maxLength
        Removed value: -20000
      • removedInput schema / properties / prompt / minLength
        Removed value: -1
      • addedInput schema / properties / source_image_urls / description
        Added value: +"Declared type: array."
    • Changedget_task1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
    • Changedtext_to_image13 fields changed
      • addedInput schema / additionalProperties
        Added value: +{}
      • removedInput schema / properties / aspect_ratio / anyOf
        Removed value: -[
-  {
-    "const": "1:1",
-    "type": "string"
-  },
-  {
-    "const": "9:16",
-    "type": "string"
-  },
-  {
-    "const": "16:9",
-    "type": "string"
-  },
-  {
-    "const": "3:4",
-    "type": "string"
-  },
-  {
-    "const": "4:3",
-    "type": "string"
-  },
-  {
-    "const": "3:2",
-    "type": "string"
-  },
-  {
-    "const": "2:3",
-    "type": "string"
-  },
-  {
-    "const": "5:4",
-    "type": "string"
-  },
-  {
-    "const": "4:5",
-    "type": "string"
-  },
-  {
-    "const": "21:9",
-    "type": "string"
-  },
-  {
-    "const": "auto",
-    "type": "string"
-  },
-  {
-    "const": "1:4",
-    "type": "string"
-  },
-  {
-    "const": "1:8",
-    "type": "string"
-  },
-  {
-    "const": "4:1",
-    "type": "string"
-  },
-  {
-    "const": "8:1",
-    "type": "string"
-  }
-]
      • addedInput schema / properties / aspect_ratio / description
        Added value: +"Declared type: string. Known values: \"1:1\", \"9:16\", \"16:9\", \"3:4\", \"4:3\", \"3:2\", \"2:3\", \"5:4\", \"4:5\", \"21:9\", \"auto\", \"1:4\", \"1:8\", \"4:1\", \"8:1\"."
      • addedInput schema / properties / aspect_ratio / type
        Added value: +"string"
      • addedInput schema / properties / callback_url / description
        Added value: +"Declared type: string."
      • removedInput schema / properties / model / enum
        Removed value: -[
-  "nano-banana",
-  "nano-banana-2",
-  "nano-banana-2-lite",
-  "nano-banana-pro"
-]
      • removedInput schema / properties / output_format / anyOf
        Removed value: -[
-  {
-    "const": "png",
-    "type": "string"
-  },
-  {
-    "const": "jpeg",
-    "type": "string"
-  },
-  {
-    "const": "jpg",
-    "type": "string"
-  }
-]
      • addedInput schema / properties / output_format / description
        Added value: +"Declared type: string. Known values: \"png\", \"jpeg\", \"jpg\"."
      • addedInput schema / properties / output_format / type
        Added value: +"string"
      • addedInput schema / properties / output_resolution / description
        Added value: +"Declared type: string."
      • addedInput schema / properties / prompt / description
        Added value: +"Declared type: string."
      • addedInput schema / properties / reference_image_urls / description
        Added value: +"Declared type: array."
      • addedInput schema / required
        Added value: +[]
  2. 5 tool updatesv0.1.12
    • Changedcheck_pricing1 field changed
      • changedInput schema / properties / model / enum
        Previous value: -[
-  "nano-banana-edit",
-  "nano-banana",
-  "nano-banana-2",
-  "nano-banana-pro"
-]New value: +[
+  "nano-banana-2-lite",
+  "nano-banana-edit",
+  "nano-banana",
+  "nano-banana-2",
+  "nano-banana-pro"
+]
    • Changededit_image14 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / aspect_ratio / anyOf
        Added value: +[
+  {
+    "const": "1:1",
+    "type": "string"
+  },
+  {
+    "const": "1:4",
+    "type": "string"
+  },
+  {
+    "const": "1:8",
+    "type": "string"
+  },
+  {
+    "const": "2:3",
+    "type": "string"
+  },
+  {
+    "const": "3:2",
+    "type": "string"
+  },
+  {
+    "const": "3:4",
+    "type": "string"
+  },
+  {
+    "const": "4:1",
+    "type": "string"
+  },
+  {
+    "const": "4:3",
+    "type": "string"
+  },
+  {
+    "const": "4:5",
+    "type": "string"
+  },
+  {
+    "const": "5:4",
+    "type": "string"
+  },
+  {
+    "const": "8:1",
+    "type": "string"
+  },
+  {
+    "const": "9:16",
+    "type": "string"
+  },
+  {
+    "const": "16:9",
+    "type": "string"
+  },
+  {
+    "const": "21:9",
+    "type": "string"
+  },
+  {
+    "const": "auto",
+    "type": "string"
+  }
+]
      • removedInput schema / properties / aspect_ratio / enum
        Removed value: -[
-  "1:1",
-  "9:16",
-  "16:9",
-  "3:4",
-  "4:3",
-  "3:2",
-  "2:3",
-  "5:4",
-  "4:5",
-  "21:9",
-  "auto"
-]
      • removedInput schema / properties / aspect_ratio / type
        Removed value: -"string"
      • addedInput schema / properties / callback_url
        Added value: +{
+  "type": "string"
+}
      • changedInput schema / properties / model / enum
        Previous value: -[
-  "nano-banana-edit"
-]New value: +[
+  "nano-banana-2-lite",
+  "nano-banana-edit"
+]
      • addedInput schema / properties / output_format / anyOf
        Added value: +[
+  {
+    "const": "png",
+    "type": "string"
+  },
+  {
+    "const": "jpeg",
+    "type": "string"
+  }
+]
      • removedInput schema / properties / output_format / enum
        Removed value: -[
-  "png",
-  "jpeg"
-]
      • removedInput schema / properties / output_format / type
        Removed value: -"string"
      • addedInput schema / properties / poll_interval_ms / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / prompt
        Added value: +{
+  "maxLength": 20000,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / source_image_urls
        Added value: +{
+  "items": {},
+  "type": "array"
+}
      • addedInput schema / properties / timeout_ms / maximum
        Added value: +9007199254740991
      • addedInput schema / required
        Added value: +[
+  "source_image_urls"
+]
    • Changedget_task1 field changed
      • changedInput schema / properties / action / description
        Previous value: -"Endpoint the task was created on."New value: +"Asynchronous endpoint the task was created on."
    • Addedlogin
    • Changedtext_to_image14 fields changed
      • removedInput schema / additionalProperties
        Removed value: -false
      • addedInput schema / properties / aspect_ratio / anyOf
        Added value: +[
+  {
+    "const": "1:1",
+    "type": "string"
+  },
+  {
+    "const": "9:16",
+    "type": "string"
+  },
+  {
+    "const": "16:9",
+    "type": "string"
+  },
+  {
+    "const": "3:4",
+    "type": "string"
+  },
+  {
+    "const": "4:3",
+    "type": "string"
+  },
+  {
+    "const": "3:2",
+    "type": "string"
+  },
+  {
+    "const": "2:3",
+    "type": "string"
+  },
+  {
+    "const": "5:4",
+    "type": "string"
+  },
+  {
+    "const": "4:5",
+    "type": "string"
+  },
+  {
+    "const": "21:9",
+    "type": "string"
+  },
+  {
+    "const": "auto",
+    "type": "string"
+  },
+  {
+    "const": "1:4",
+    "type": "string"
+  },
+  {
+    "const": "1:8",
+    "type": "string"
+  },
+  {
+    "const": "4:1",
+    "type": "string"
+  },
+  {
+    "const": "8:1",
+    "type": "string"
+  }
+]
      • removedInput schema / properties / aspect_ratio / enum
        Removed value: -[
-  "1:1",
-  "9:16",
-  "16:9",
-  "3:4",
-  "4:3",
-  "3:2",
-  "2:3",
-  "5:4",
-  "4:5",
-  "21:9",
-  "auto",
-  "1:4",
-  "1:8",
-  "4:1",
-  "8:1"
-]
      • removedInput schema / properties / aspect_ratio / type
        Removed value: -"string"
      • addedInput schema / properties / callback_url
        Added value: +{
+  "type": "string"
+}
      • changedInput schema / properties / model / enum
        Previous value: -[
-  "nano-banana",
-  "nano-banana-2",
-  "nano-banana-pro"
-]New value: +[
+  "nano-banana",
+  "nano-banana-2",
+  "nano-banana-2-lite",
+  "nano-banana-pro"
+]
      • addedInput schema / properties / output_format / anyOf
        Added value: +[
+  {
+    "const": "png",
+    "type": "string"
+  },
+  {
+    "const": "jpeg",
+    "type": "string"
+  },
+  {
+    "const": "jpg",
+    "type": "string"
+  }
+]
      • removedInput schema / properties / output_format / enum
        Removed value: -[
-  "png",
-  "jpeg",
-  "jpg"
-]
      • removedInput schema / properties / output_format / type
        Removed value: -"string"
      • removedInput schema / properties / output_resolution / enum
        Removed value: -[
-  "1k",
-  "2k",
-  "4k"
-]
      • addedInput schema / properties / poll_interval_ms / maximum
        Added value: +9007199254740991
      • addedInput schema / properties / prompt
        Added value: +{
+  "type": "string"
+}
      • addedInput schema / properties / reference_image_urls
        Added value: +{
+  "items": {},
+  "type": "array"
+}
      • addedInput schema / properties / timeout_ms / maximum
        Added value: +9007199254740991
  3. 4 tool updatesv0.1.0
    • First observedcheck_pricing
    • First observededit_image
    • First observedget_task
    • First observedtext_to_image
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: auth (login), pricing lookup (check_pricing), two creation paths split by modality (edit_image vs text_to_image), and polling (get_task). No two tools overlap—edit_image and text_to_image are cleanly separated by whether an input image is involved, while get_task handles result retrieval.

Naming Consistency4/5

Consistent snake_case verb_noun convention (check_pricing, edit_image, text_to_image, get_task). The lone exception is 'login', a bare verb with no object, though it stays in snake_case and is unambiguous.

Tool Count5/5

Five tools is well-scoped for a single model-line integration: authentication, pricing, two generation modes, and result polling. Each tool earns its place with no redundancy or filler.

Completeness4/5

Covers the core lifecycle—authenticate, check cost, submit edit/text-to-image tasks, and poll results. Minor gaps exist: no list_tasks or cancel/delete task operation, and no explicit reference-image upload, but agents can work around these.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers