Nano Banana MCP
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Each tool has a distinct role, but edit_image and continue_editing both modify an image based on a prompt, so an agent might briefly hesitate between them. The dependency note on continue_editing and the 'existing image' wording in edit_image reduces but does not eliminate this overlap.
Naming Consistency5/5All tool names use a consistent snake_case verb-first pattern: list_models, generate_image, edit_image, configure_auth, get_status, get_last_image. continue_editing fits the same pattern despite using a gerund rather than a simple noun.
Tool Count5/5Seven tools is well-scoped for a focused image-generation/editing server. Each tool covers a necessary part of the workflow without redundancy or bloat.
Completeness5/5The surface covers authentication, model discovery, generation, editing, iterative refinement, status checking, and access to the latest output metadata. There are no obvious dead ends; model selection is handled via parameters, and image files are returned as paths.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal that this is a mutating operation. The description adds useful behavioral context by naming the model family (Google Gemini image models), the side effect of saving the image, and the return form (file path). No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action, indicates the model provider, and states the return value. It contains no filler, repetition, or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple generation tool with fully documented parameters and an output schema, the description covers the essential behavior and result. It does not mention setup requirements such as authentication, but the presence of a configure_auth sibling and the overall context make this a minor gap rather than a blocking one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: all three parameters already have meaningful descriptions, enums, defaults, and an example for prompt. The description adds no parameter-specific detail, but it does not need to because the schema carries the full semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a new image from a text prompt', which clearly differentiates this from editing-oriented siblings like edit_image and continue_editing. It does not explicitly name those alternatives, so it stops short of a 5, but the purpose 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: this is for generating a brand-new image from a text prompt, which distinguishes it from image-editing tools. However, there is no explicit guidance about when not to use it or which sibling to choose for editing or continuation tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already convey that this is not read-only and not idempotent. The description adds useful behavioral detail by mentioning that the result is saved and its file path returned, but it does not explain whether the original file is overwritten or a new file is created. This is a moderate gap, not a contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler. The core action, optional input, and return value are all stated efficiently and in a sensible order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complete schema coverage, an output schema, and clear annotations, the description captures the essential behavior well. It could be slightly stronger by noting how this differs from continue_editing or clarifying save behavior, but overall an agent has enough to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 four parameters in detail. The description adds a small clarification that referenceImages are for 'style guidance', which is consistent with the schema. It does not add substantial new parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Edit an existing image using a text prompt.' This clearly differentiates the tool from the sibling generate_image, which is about creating new images, and it also states the return behavior ('Returns the file path of the saved result').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when editing an existing image, and optionally supply reference images for style guidance. It does not explicitly name alternatives or state when not to use it, but the 'existing image' framing makes the intended use apparent relative to generate_image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait beyond the annotations: the operation depends on prior session state ('last generated or edited image') and returns a file path. This is meaningful context beyond readOnlyHint, openWorldHint, and destructiveHint. It does not, however, explain what happens if no prior image exists or whether the original file is replaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The description front-loads the core action, states the prerequisite, and ends with the return value. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with full schema coverage and an output schema, the description provides the core behavior, the prerequisite, and the return artifact. It leaves minor edge conditions to inference, such as failure behavior when no prior image exists, but overall the agent has enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the prompt and model parameters, including a prompt example and model enum values. The description adds little beyond calling the prompt 'a new prompt' and connecting it to the last generated/edited image. Baseline 3 is appropriate because the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Refine the last generated or edited image with a new prompt.' It clearly differentiates this from generate_image and edit_image by focusing on the existing last image rather than creating or editing from scratch. An agent can immediately understand the tool's role in the image workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit prerequisite: 'Must call generate_image or edit_image first.' This makes the sequential usage context clear. It does not explicitly state when not to use this tool or contrast it with alternatives, but the prerequisite plus 'last generated or edited image' strongly implies the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply idempotentHint=true and destructiveHint=false. The description adds relevant context by clarifying the operation configures authentication and by pointing to the key source. It does not detail persistence or overwrite behavior, but the annotation coverage reduces the need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler: the action is front-loaded and the key-source instruction earns its place. Nothing extraneous is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, idempotent configuration tool with an output schema and full schema coverage, the description is complete. It gives the single input, its source, and the purpose; an agent has what it needs to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents apiKey with the same Google AI Studio URL and a minLength constraint, so schema coverage is 100%. The description only repeats the source link rather than adding new parameter meaning, which lands at the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set') on a specific resource ('Gemini API key') and ties it to 'authentication'. That scope is clearly distinct from the sibling image/model/status tools, so an agent can tell it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It communicates the intended use case—setting up authentication—and tells the user where to obtain the key. There are no overlapping sibling tools to exclude, though it could more explicitly say to run this before other Gemini API calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail by specifying the scope ('most recently generated or edited') and enumerating the returned metadata fields, which is especially useful since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the action, resource, and return fields without any filler. Every part earns its place, and the most important qualifier ('most recently') appears early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, read-only tool, the description adequately covers what the agent needs to know: what it returns and how the target is selected. It could mention edge-case behavior (e.g., when no image exists yet), but this is a minor gap given the low complexity and clear annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4; the schema fully covers the parameter surface. The description's mention of 'most recently generated or edited' helps clarify what the implicit selection criterion is.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get metadata') and names the exact resource ('the most recently generated or edited image') with the fields returned (file path, MIME type, timestamp, size). This clearly distinguishes it from sibling tools like generate_image, edit_image, and list_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'most recently generated or edited image' gives clear contextual guidance: use this tool when you need metadata about the latest image from generation or editing workflows. It does not explicitly name alternatives or exclusion conditions, but the usage context is evident from the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering side-effect safety. The description adds value by specifying exactly what state is inspected, which is useful behavioral context beyond the generic read-only flag. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The first lists the inspected state; the second gives the intended use case. No filler, no redundancy, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter, read-only status tool, the description covers purpose, scope, and usage timing. The presence of an output schema handles return-value documentation, and annotations cover safety, so nothing necessary is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description carries no parameter burden. Per baseline for a 0-parameter tool, this is a 4; the description appropriately says nothing about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear, specific verb ('Check') and names three concrete resources: authentication state, active model, and image output directory. This clearly distinguishes the tool from siblings like list_models or generate_image, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this to verify setup before generating images.' However, it does not mention alternatives or cases where one would not use it, so it doesn't fully meet the 'when-not' and 'alternatives' criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context by specifying the result includes all available models and the fields returned, which goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the core purpose and output, and the second sentence adds actionable guidance about using the returned model IDs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple zero-parameter read-only list operation with an output schema, so the description does not need to explain return values. It covers what the tool returns and how the results are meant to be used, making it complete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so parameter documentation is not needed. The description adds no parameter semantics, but the baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a specific resource ('all available Gemini image models'), and the exact output fields ('product name, ID, and whether they are the default'). This clearly separates it from the image-generation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly connects the tool's output to its consumers: 'Use model IDs when calling generate_image, edit_image, or continue_editing.' This gives clear context for when to call this tool, though it does not explicitly state when not to use it or mention alternatives for listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md: