Click on "Deploy 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., "@NanoBanana MCP Generate an image of a cyberpunk city at sunset"
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.
MCP server that brings Gemini's image generation and editing capabilities to Claude Desktop, Claude Code, and Cursor. Supports Nano Banana 2 (Flash) and Nano Banana Pro models.
Image Generation - Create 2K images from text prompts
Image Editing - Transform images with natural language instructions
Session Consistency - Maintain style/character across generations
Runtime Model Switching - Switch between Flash and Pro models without restart
Multi-turn Chat - Conversational context with image support
Related MCP server: nb-mcp
Node.js 18+
Google AI API Key (Get one here)
claude mcp add nanobanana-mcp -- npx -y @ycse/nanobanana-mcp \
-e "GOOGLE_AI_API_KEY=your_api_key"Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"nanobanana-mcp": {
"command": "npx",
"args": ["-y", "@ycse/nanobanana-mcp"],
"env": {
"GOOGLE_AI_API_KEY": "your_api_key"
}
}
}
}Create or edit .cursor/mcp.json (project-level) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"nanobanana-mcp": {
"command": "npx",
"args": ["-y", "@ycse/nanobanana-mcp"],
"env": {
"GOOGLE_AI_API_KEY": "your_api_key"
}
}
}
}See Cursor MCP Documentation for more details.
Tool | Purpose |
| Required. Set aspect ratio before image generation |
| Switch between flash/pro models at runtime |
| Generate images from text prompts |
| Edit images with natural language |
| Multi-turn conversation with images |
| View session image history |
| Reset session context |
Must be called before generating or editing images.
Valid ratios: 1:1, 9:16, 16:9, 3:4, 4:3, 3:2, 2:3, 5:4, 4:5, 21:9Switch models per-session without restarting:
Value | Model | Description |
| gemini-3.1-flash-image-preview | Nano Banana 2 - Faster (default) |
| gemini-3-pro-image-preview | Nano Banana Pro - Higher quality |
{
prompt: string; // Image description
aspect_ratio?: string; // Override session ratio
output_path?: string; // Save path (default: ~/Documents/nanobanana_generated/)
conversation_id?: string; // Session ID
use_image_history?: boolean; // Use previous images for consistency
reference_images?: string[]; // Reference images for style
}{
image_path: string; // File path, "last", or "history:N"
edit_prompt: string; // Edit instructions
aspect_ratio?: string; // Override session ratio
output_path?: string; // Save path
conversation_id?: string; // Session ID
reference_images?: string[]; // Style references
}npx @ycse/nanobanana-mcp --install-commands claude-code
# Or manually:
# mkdir -p ~/.claude/commands
# cp commands/claude-code/*.md ~/.claude/commands/npx @ycse/nanobanana-mcp --install-commands cursor
# Or manually:
# mkdir -p .cursor/commands
# cp commands/cursor/*.md .cursor/commands/See Cursor Slash Commands for more details.
/nb-flash - Switch to Flash model (faster)
/nb-pro - Switch to Pro model (higher quality)1. Set aspect ratio: set_aspect_ratio("16:9")
2. Generate: "A cyberpunk cityscape at sunset"// First image
{ prompt: "A red-hat cat", conversation_id: "cat" }
// Second image - same character
{ prompt: "The cat taking a nap", conversation_id: "cat", use_image_history: true }// Edit the last generated image
{ image_path: "last", edit_prompt: "Change hat to blue" }
// Edit specific image from history
{ image_path: "history:0", edit_prompt: "Add sunglasses" }// Start with Flash for quick iterations
set_model({ model: "flash" })
{ prompt: "Draft concept art" }
// Switch to Pro for final render
set_model({ model: "pro" })
{ prompt: "Final polished version", use_image_history: true }Variable | Required | Description |
| Yes | Google AI API key |
| No | Default model ( |
Generated images save to ~/Documents/nanobanana_generated/:
Generated: generated_[timestamp].png
Edited: [original]_edited_[timestamp].png
git clone https://github.com/YCSE/nanobanana-mcp.git
cd nanobanana-mcp
npm install
npm run dev # Development mode with hot reload
npm run build # Production build
npm run start # Run compiled serverImage generation fails:
Verify API key is valid
Check quota at Google AI Studio
Ensure set_aspect_ratio was called first
Tools not showing:
Restart Claude Desktop/Code
Check config file syntax
Verify npx -y @ycse/nanobanana-mcp runs without errors
MIT
Clear conversation history for a specific conversation ID
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | The conversation ID to clear |
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 indicates a destructive action ('clear') but does not state whether the operation is irreversible, affects persistent storage, requires specific permissions, or what the outcome will be. This is a significant gap for a mutation tool.
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 a single, front-loaded sentence that states the action and object directly. Every word adds value, with no redundancy or filler.
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?
For a simple tool with one parameter and no output schema, the description still omits critical behavioral context such as permanence of deletion, side effects on active chat sessions, or whether any confirmation is required. The lack of annotations and output schema places the burden on the description, which does not meet it.
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%, as the only parameter (conversation_id) is described as 'The conversation ID to clear'. The tool description adds no additional semantic detail beyond referencing 'a specific conversation ID', which matches the schema. Thus the 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 action ('Clear') and the resource ('conversation history') with a specific scope ('for a specific conversation ID'). It is unambiguous and distinguishes itself from sibling tools, which handle image generation, chat, and model settings.
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 (call this when you need to clear a conversation's history) but provides no explicit guidance on when to use it versus alternatives or any exclusions. Since no sibling performs a similar function, explicit alternative guidance is not necessary, but the description still lacks any context about prerequisites or suitability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Chat with Gemini 3.1 Flash model. Supports multi-turn conversations with up to 10 reference images.
| Name | Required | Description | Default |
|---|---|---|---|
| images | No | Array of image paths to include in the chat (max 10). Supports file paths, 'last', or 'history:N' references. | |
| message | Yes | The message to send to Gemini | |
| system_prompt | No | Optional system prompt to guide the model's behavior | |
| conversation_id | No | Optional conversation ID for maintaining context and accessing image history |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses multi-turn support and image limit, but omits return format, authentication/rate limits, and side effects. For an external API call, this is a partial disclosure; not misleading but incomplete.
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?
A single, front-loaded sentence that immediately identifies the action and resource. It adds two key capabilities without waste.
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, so the description should clarify what the tool returns (e.g., text response), but it does not. It also lacks practical guidance on using conversation_id for multi-turn beyond the schema, leaving gaps for a 4-parameter tool with no annotations.
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 baseline 3. The description adds context like 'multi-turn' (relating to conversation_id) and 'reference images,' but these are largely redundant with the schema's own parameter descriptions.
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: 'Chat with Gemini 3.1 Flash model.' It uses a specific verb and resource, and the mention of multi-turn and reference images distinguishes it from sibling image generation/editing and conversation management 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?
Usage is implied: this is the chat tool. However, there is no explicit guidance on when to use it versus siblings like clear_conversation or set_model, nor prerequisites for multi-turn (e.g., conversation_id). The description implies but does not instruct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit or modify existing images based on prompts. Supports session history references ('last' or 'history:N') and image consistency features.
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes | Path to the original image. Use 'last' for most recent generated image, or 'history:N' (e.g., 'history:0') to reference by index | |
| edit_prompt | Yes | Instructions for how to edit the image | |
| output_path | No | Optional output path. If not provided, saves to ~/Documents/nanobanana_generated/ | |
| aspect_ratio | No | Aspect ratio for the edited image. Overrides session setting if provided. | |
| conversation_id | No | Session ID for accessing image history and maintaining consistency | |
| reference_images | No | Additional reference images for style consistency (max 10). Supports file paths, 'last', or 'history:N' references. | |
| enable_google_search | No | Enable Google Search for real-world reference grounding |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It mentions session history references and 'image consistency features,' but doesn't explain what the tool returns, whether the original image is modified or a new file is created, or any side effects like default save location (which appears only in the schema). This is insufficient for a tool that modifies files.
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 just two sentences, front-loaded with the core purpose and followed by a useful capability note. There is no wasted wording, and it avoids repeating schema details. It's concise and directly readable, though the phrase 'image consistency features' is slightly vague but not excessive.
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 (7 parameters) and absence of an output schema, the description should explain return values and behavioral outcomes, but it doesn't. It also leaves 'image consistency features' undefined, forcing the agent to infer from the schema. Missing information about default output behavior and effects on the original image makes the description incomplete for safe autonomous use.
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 parameter meanings are already documented. The description's mention of history references and consistency adds no new information beyond the schema's detailed parameter descriptions. Baseline 3 is appropriate because 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 identifies the tool's purpose: 'Edit or modify existing images based on prompts.' The verb 'edit/modify' plus the resource 'existing images' distinguishes it from sibling gemini_generate_image, which creates new images. It also mentions key capabilities like history references, making the purpose unambiguous.
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—edit existing images when you have a prompt—but provides no explicit guidance on when to use this tool versus alternatives like gemini_generate_image or gemini_chat. It doesn't state exclusions or name alternative tools for different scenarios, so guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate images using Gemini's image generation capabilities. Supports session-based image consistency for maintaining style/character across multiple generations.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Description of the image to generate | |
| output_path | No | Optional path where to save the generated image. If not provided, saves to ~/Documents/nanobanana_generated/ | |
| aspect_ratio | No | Aspect ratio for the generated image. Overrides session setting if provided. | |
| conversation_id | No | Session ID for maintaining image history and consistency across generations | |
| reference_images | No | Array of file paths to reference images for style/character consistency | |
| use_image_history | No | If true, includes previous generated images from this session for style/character consistency | |
| enable_google_search | No | Enable Google Search for real-world reference grounding |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing side effects and behaviors. It fails to mention that the tool saves images to disk (defaulting to ~/Documents/nanobanana_generated/), any network/API usage, authentication requirements, or return values. It only mentions session-based consistency, which is a feature but not a behavioral disclosure.
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 short sentences that front-load the core purpose. Every word adds value, and there is no redundancy or filler.
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?
Despite a 7-parameter schema and no output schema, the description does not explain the tool's overall behavior (e.g., where the generated image goes, what the tool returns, or how the session mechanism operates). The session consistency mention is a start, but the description is too sparse for the complexity involved.
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 all seven parameters are already documented in the schema. The description adds no new parameter-level semantics beyond what the schema provides, making the baseline 3 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 generates images via Gemini, and mentions a key differentiator (session-based image consistency) that distinguishes it from siblings like gemini_chat or gemini_edit_image. The verb and resource are specific and unambiguous.
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 the tool is for generating new images and optionally using session consistency, but it does not explicitly address when to use this tool versus alternatives like gemini_edit_image or gemini_chat. No exclusion criteria or alternative recommendations are given, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the list of generated/edited images in a session for reference
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | The session ID to get image history for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states the tool retrieves a list ('Get the list'), which suggests a read-only operation, but it does not explicitly confirm it has no side effects, or describe output details or limitations. The behavior is basic but adequately conveyed.
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 a single, front-loaded sentence with no filler. It communicates the essential purpose in eleven 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?
For a simple tool with one parameter and no output schema, the description provides enough information: it tells the user what the tool returns (a list of images) and the scope (session). No significant gaps are present.
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 fully describes the only parameter (conversation_id), and the description does not add any new details about format or semantics beyond confirming it is session-based. With 100% schema coverage, the baseline 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 uses the specific verb 'Get' and the resource 'list of generated/edited images in a session'. This clearly distinguishes it from sibling tools like gemini_generate_image or gemini_edit_image.
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 phrase 'for reference' implies a use case of retrieving past images, but it does not explicitly state when to prefer this tool over others or mention alternatives/exclusions. The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the aspect ratio for subsequent image generation and editing in this session. Must be called before generating/editing images if a specific ratio is desired.
| Name | Required | Description | Default |
|---|---|---|---|
| aspect_ratio | Yes | The aspect ratio to use for image generation/editing | |
| conversation_id | No | Session ID to apply this setting to (default: 'default') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the session-scoped effect and the ordering requirement, but does not clarify behavior like overriding previous settings, persistence across sessions, or the relationship between 'session' and the conversation_id parameter.
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, front-loaded with the verb and key resource, followed immediately by the usage rule. 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?
For a simple setter tool with a fully described schema, the description covers core purpose and usage timing. Minor ambiguity exists around 'session' vs conversation_id and default ratio behavior, but overall it is sufficiently complete for the tool's simplicity.
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%: both parameters have descriptions, and aspect_ratio has a detailed enum. The description adds no additional parameter semantics, so baseline 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's function: 'Set the aspect ratio for subsequent image generation and editing in this session.' It uses a specific verb and resource, and distinguishes itself from sibling tools like set_model and the actual image generation/editing 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?
Explicit guidance is given: 'Must be called before generating/editing images if a specific ratio is desired.' This states when to use the tool and the condition under which it applies, though it does not mention alternatives or explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the Gemini model for this session. 'flash' for faster generation (default), 'pro' for higher quality.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model to use: 'flash' (gemini-3.1-flash-image-preview) or 'pro' (gemini-3-pro-image-preview) | |
| conversation_id | No | Session ID to apply this setting to (default: 'default') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It states the action ('set') but omits any side effects, persistence, session scope semantics, or whether changing the model affects existing conversations. The word 'session' hints at scope but lacks explicit detail, leaving the agent to infer the behavioral contract.
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. The first sentence immediately identifies the action and scope; the second adds necessary selection guidance. No words are wasted, and the structure is front-loaded.
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?
For a simple setter tool with full schema coverage, the description is mostly adequate. However, it lacks any mention of return value or confirmation, and without annotations it does not address persistence or side effects. Given the low complexity, this is a moderate gap; the description is complete enough to use but not fully self-contained.
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 the parameter semantics are already well-documented. The description adds value by clarifying the trade-off between 'flash' and 'pro' (speed vs. quality), which supplements the schema's enum descriptions. However, it does not mention the conversation_id parameter or its default, but since the schema covers that and the description's 'for this session' hints at it, a 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 verb ('Set') and resource ('the Gemini model for this session'), making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like gemini_chat or gemini_generate_image by focusing on session-level configuration.
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?
Provides explicit guidance on when to choose each model value: 'flash' for faster generation and 'pro' for higher quality, which is directly actionable for the primary parameter. However, it does not explicitly mention alternatives like set_aspect_ratio or when not to use this tool, though that context is somewhat implied by the sibling set.
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.
v1.1.1clear_conversationgemini_chatgemini_edit_imagegemini_generate_imageget_image_historyset_aspect_ratioset_modelScored across 7 tools
Each tool has a clearly distinct purpose: retrieving history, chatting, generating images, editing images, clearing conversation, and setting session parameters. There is no functional overlap between generate and edit, and chat is text-focused while image tools are visual. Even the history and clear tools are unambiguous (images vs. conversation).
Most tools follow a verb_noun pattern (get_image_history, clear_conversation, set_aspect_ratio, set_model), but three tools are prefixed with 'gemini_' (gemini_chat, gemini_generate_image, gemini_edit_image), creating an inconsistency in form. The verbs are clear, but the prefix usage is not uniform, and 'gemini_chat' reads more as a noun phrase than a verb_noun command.
Seven tools is a well-scoped count for a server focused on image generation/editing and session management. Each tool serves a necessary function without redundancy or bloat, fitting comfortably within the ideal 3-15 range.
The surface covers the main lifecycle for image work: generate (create), edit (update), view history (read), and session management. The only minor gap is the lack of an explicit delete/image removal tool and no way to view conversation history outside of image history, but these are workarounds in most use cases.
MCP server for NanoBanana AI image generation and editing
MCP server for Qwen Image 3 AI image generation
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
