Generate and edit images with OpenAI's GPT Image 2.5 via the you.bot API, and check your credit balance.
generate_image: Create a 1024px image from a text prompt (costs 2.9 credits / $0.029). Supports aspect ratios from 1:1 to 21:9.
edit_image: Modify an existing image from a public URL — change, add, remove, or restyle elements while keeping the rest (costs 2.9 credits / $0.029).
check_credits: View your remaining you.bot credit balance and how many images it buys (free).
Requires a you.bot API key (YOUBOT_API_KEY), not an OpenAI key; free signup gives 50 credits (~17 images).
Generates and edits images using OpenAI's GPT Image 2.5 model, supporting text-to-image prompts, editing existing images from URLs, multiple aspect ratios, and credit balance checking.
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., "@youbot-image-mcp create a photo of a golden retriever wearing sunglasses on a beach"
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.
Generate and edit images with GPT Image 2.5 — OpenAI's most capable image model — directly inside Claude, Cursor, or any MCP client. $0.029 per image.
Ask Claude for a picture and get one back in the chat:
"A friendly robot painting a picture at an easel in a sunlit studio, warm morning light through a tall window, soft shadows, detailed illustration style, a small wooden sign on the easel reading 'GPT IMAGE 2.5'"
Generated with this server in 45 seconds for $0.029. Note that the text on the sign came out exactly as asked — GPT Image 2.5 is unusually good at rendering words inside an image.
This server reaches GPT Image 2.5 through you.bot, an API gateway that resells the model below OpenAI's own rate.
You need a you.bot API key. It starts with sk-live-.
An OpenAI key will not work, and you do not need an OpenAI account at all.
If you paste an OpenAI key by mistake, the server will tell you so by name rather than failing with a confusing 401.
Why people use it: signup gives you 50 free credits — about 17 images — with no credit card, so the server works the moment you paste the key in.
Related MCP server: @genoooool/mcp-image-generator
Sign up at https://you.bot — no credit card.
You start with 50 credits ≈ 17 images.
Create a key at https://you.bot/dashboard/api-keys and copy it (it begins with sk-live-).
Edit claude_desktop_config.json
(macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\):
{
"mcpServers": {
"gpt-image": {
"command": "npx",
"args": ["-y", "gpt-image-2-5-mcp"],
"env": {
"YOUBOT_API_KEY": "sk-live-your-key-from-you.bot"
}
}
}
}Restart Claude Desktop.
claude mcp add gpt-image -e YOUBOT_API_KEY=sk-live-your-key -- npx -y gpt-image-2-5-mcpIn ~/.cursor/mcp.json (or Settings → MCP → Add new server):
{
"mcpServers": {
"gpt-image": {
"command": "npx",
"args": ["-y", "gpt-image-2-5-mcp"],
"env": { "YOUBOT_API_KEY": "sk-live-your-key-from-you.bot" }
}
}
}Run npx -y gpt-image-2-5-mcp over stdio with YOUBOT_API_KEY in the environment.
Ask your assistant: "check my image credits". You should see your balance and how many images it buys.
Tool | What it does | Cost |
| Make an image from a text prompt | 2.9 credits ($0.029) |
| Change an existing image from a public URL — swap a background, add or remove objects, restyle | 2.9 credits ($0.029) |
| Show remaining balance and images left | free |
There is also a setup prompt that walks you through configuration if something isn't working.
Aspect ratios: 1:1 (default), 3:2, 2:3, 4:3, 3:4, 16:9, 9:16, 2:1, 1:2, 21:9
Output is fixed at 1024px (1K), which is what keeps every call at a flat $0.029. A generation typically takes 30–60 seconds; the server polls until the image is ready and then shows it to you inline.
Per image | $0.029 |
Free on signup | 50 credits ≈ 17 images, no card |
Credit value | 1 credit = $0.01 |
Expiry | Credits never expire |
Failed generations | Refunded automatically |
The server tells you the cost after every image, and check_credits never spends anything.
Environment variable | Effect |
| Required. Your you.bot key ( |
| If set, every generated image is also saved to this folder as a PNG |
GPT Image 2.5 rewards long, specific prompts. Describe subject, setting, lighting, composition and style instead of stacking keywords.
It also renders text inside images accurately — so if you want words on a poster or a sign, quote them exactly:
"A minimalist café sign reading 'OPEN DAILY 7AM' in clean sans-serif, warm morning light, shallow depth of field"
For edit_image, say what should change and what should stay:
"Replace the background with a snowy forest. Keep the subject, pose and lighting unchanged."
"No API key found" — YOUBOT_API_KEY isn't reaching the server. Check it's inside the env block of your MCP config, then fully restart the client.
"That key looks like an OpenAI API key" — exactly what it says. Get a key from https://you.bot instead; it starts with sk-live-.
"Out of credits" — each image is 2.9 credits. Top up at https://you.bot; credits never expire.
Nothing happens / tool isn't offered — confirm your client picked the server up (Claude Desktop lists it under the tools icon), and that you have Node 18 or newer.
Model and live pricing — https://you.bot/models/gpt-image-2-5-sunburst-text-to-image
API docs — https://you.bot/docs
Get a key — https://you.bot
MIT licensed. Not affiliated with OpenAI; GPT Image 2.5 is accessed through the you.bot API.
Check the remaining you.bot credit balance and how many more images it buys. Free and instant — does not generate anything. Requires a you.bot API key in YOUBOT_API_KEY — NOT an OpenAI key. Free key with 50 starting credits (~17 images) at https://you.bot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that the tool is free, instant, non-generative, and requires a specific API key. It also mentions the starting credits and where to get a key. It doesn't describe error handling or output format, but for a zero-parameter balance check, the key behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, then efficiently packs prerequisites, exclusions, and a resource link. Every sentence earns its place; no fluff.
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 zero-parameter tool with no output schema, the description is complete: it states what is checked, the authentication requirement, the non-generative nature, and how to obtain a key. An agent can call it correctly without further context.
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 tool has zero parameters and 100% schema coverage (empty object), so the baseline is 4. The description adds no parameter-specific info because none exist, but it does explain the context of the check (credit balance and image count) which is relevant to how the tool is invoked.
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 states a specific verb ('Check') and resource ('remaining you.bot credit balance'), and explicitly disambiguates from siblings by noting it 'does not generate anything.' This is distinct from generate_image and 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 description provides clear prerequisites (requires YOUBOT_API_KEY, not OpenAI key) and a hint of when to use it (free, instant, for checking balance). It doesn't explicitly say 'use before generate_image' but the exclusion 'does not generate anything' implies it's a preliminary check. Slight gap in explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing image with GPT Image 2.5 — change, add, remove or restyle parts of it while keeping the rest. Takes a publicly reachable image URL and a description of the change. $0.029 per edit (2.9 credits), 1024px output. Requires a you.bot API key in YOUBOT_API_KEY — NOT an OpenAI key. Free key with 50 starting credits (~17 images) at https://you.bot.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The change to make, e.g. 'replace the background with a snowy forest, keep the subject and lighting unchanged'. | |
| image_url | Yes | Public https URL of the source image. Local file paths do not work — the image must be reachable from the internet. | |
| aspect_ratio | No | Shape of the output image. Defaults to 1:1 (square). | 1:1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly: it discloses cost per edit, output size, API key requirement, key provider distinction, and free-credit availability. It also flags the operational constraint that the input image must be publicly reachable. This is substantial, non-obvious behavioral context.
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 purpose is front-loaded, and every sentence earns its place: operation, input requirements, cost/output size, and authentication details. Despite packing in several details, the description remains tight and readable with no 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?
The definition is largely complete for invocation: inputs, cost, auth, output size, and URL constraints are all covered. Since there is no output schema, stating what the tool returns (e.g., an edited image URL or binary) would close the remaining gap, but the current description still gives the agent 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description loosely restates image_url as 'publicly reachable image URL' and prompt as 'description of the change', but adds no meaning beyond what the schema already provides. Aspect_ratio is absent from the description and is already fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb plus resource: 'edit an existing image', and enumerates allowed operations ('change, add, remove or restyle parts of it while keeping the rest'). This clearly differentiates the tool from its sibling generate_image, which is for creating new images.
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 intended use context is clear: edit an existing publicly reachable image with a prompt describing the change. It also states prerequisites like needing a public URL and a you.bot API key. However, it does not explicitly direct the agent to generate_image for new images or check_credits for balance inquiries, so exclusions are implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt using GPT Image 2.5 (OpenAI's most capable image model) at $0.029 per image, 1024px. Good at photorealism, illustration, and rendering readable text inside the image. Costs 2.9 credits per call. Requires a you.bot API key in YOUBOT_API_KEY — NOT an OpenAI key. Free key with 50 starting credits (~17 images) at https://you.bot.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | What to draw. Long, specific descriptions work best — subject, setting, lighting, composition, style. To put words in the image, quote them exactly. | |
| aspect_ratio | No | Shape of the image. Defaults to 1:1 (square). | 1:1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses authentication requirements ('Requires a you.bot API key in YOUBOT_API_KEY — NOT an OpenAI key'), cost ('$0.029 per image', '2.9 credits per call'), and output resolution ('1024px'). It doesn't mention rate limits or return format, but the core behavioral constraints are covered.
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?
Every sentence earns its place: purpose and model, capability, cost, credits, API key requirement and free key link. It's informative yet compact, with the most critical information (what it does) front-loaded before cost and authentication details.
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 two-parameter tool with 100% schema coverage and no output schema, the description covers the essential invocation context: how to generate (prompt guidance), auth, cost, and output size. It doesn't specify the exact return format (URL or file), but this is a minor gap given the tool's simplicity and the sibling tools that suggest downstream usage (edit_image, check_credits).
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 prompt and aspect_ratio have detailed schema descriptions. The tool-level description adds little beyond the schema: it restates prompt advice (quote text) that already appears in the schema. With full schema coverage, a 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 explicitly states 'Generate an image from a text prompt using GPT Image 2.5', which includes a specific verb and resource. It also lists capabilities (photorealism, illustration, readable text) and distinguishes from siblings like edit_image by focusing on generation rather than editing.
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 gives clear usage context: 'Good at photorealism, illustration, and rendering readable text inside the image', plus prerequisite authentication (you.bot API key, not OpenAI key) and cost. It doesn't explicitly state 'use edit_image instead when editing', but the generation vs editing distinction is strongly implied by the description and sibling tool names.
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.0check_creditsedit_imagegenerate_imageScored across 3 tools
Each tool has a clearly distinct purpose: generate new images, edit existing images, or check credits. There is no functional overlap between any of the three tools.
All tool names follow a consistent verb_noun pattern in snake_case: generate_image, check_credits, edit_image. The naming convention is uniform and predictable.
Three tools is a well-scoped count for an image generation/editing MCP server. Each tool covers a necessary operation without unnecessary bloat or redundancy.
The server covers the core domain completely: create an image, edit an image, and verify account credits. There are no obvious missing operations for the stated purpose of image generation and editing.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
Generate AI images and videos from any compatible MCP client.
AI voice generation: text-to-speech and voice cloning from any MCP client.
MCP server for NanoBanana AI image generation and editing
