Provides tools for generating, editing, and manipulating images using Stability AI models on AWS Bedrock, enabling AI agents to create images, remove backgrounds, transfer styles, upscale, and more.
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., "@mcp-server-bedrock-image generate an image of a sunset over mountains"
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.
An MCP (Model Context Protocol) server that gives AI agents the ability to generate, edit, and manipulate images using Stability AI models on AWS Bedrock.
Connect it to Claude Code, Cursor, Windsurf, VS Code, or any MCP-compatible client — then ask your AI to generate images, remove backgrounds, transfer styles, upscale, and more.
Tool | What it does | Model |
| High-quality text-to-image generation | Stable Image Ultra |
| Faster, lower-cost generation | Stable Image Core |
| Remove image background | Stability Remove Background v1 |
| Apply style from a reference image | Stability Style Transfer v1 |
| Recolor specific elements by description | Stability Search & Recolor v1 |
| Extend image in any direction | Stability Outpaint v1 |
| Find and replace objects in an image | Stability Search & Replace v1 |
| 4x resolution upscale | Stability Fast Upscale v1 |
| Creative upscale up to 4K | Stability Creative Upscale v1 |
| Composition-aware logo overlay | Local (Pillow — no Bedrock call) |
Related MCP server: AWS Nova Canvas MCP Server
Python 3.12+
AWS account with Bedrock access to Stability AI models
uv package manager
# Run directly (no install needed)
uvx mcp-server-bedrock-image
# Or install globally
uv tool install mcp-server-bedrock-imageTwo auth modes are supported:
boto3 mode (default) — Uses standard AWS credential chain (env vars, ~/.aws/credentials, IAM roles, STS):
export AWS_REGION=us-west-2Bearer token mode — Uses Bedrock API keys (no AWS CLI setup needed):
export BEDROCK_AUTH_MODE=bearer
export AWS_BEARER_TOKEN_BEDROCK=your-api-key-here
export AWS_REGION=us-west-2Add to .claude/settings.json:
{
"mcpServers": {
"bedrock-image": {
"command": "uvx",
"args": ["mcp-server-bedrock-image"],
"env": {
"AWS_REGION": "us-west-2",
"IMAGE_STORAGE_DIRECTORY": ".content-workspace/images"
}
}
}
}For bearer token auth, add "BEDROCK_AUTH_MODE": "bearer" and "AWS_BEARER_TOKEN_BEDROCK": "your-api-key" to the env block.
Add to .cursor/mcp.json:
{
"mcpServers": {
"bedrock-image": {
"command": "uvx",
"args": ["mcp-server-bedrock-image"],
"env": {
"AWS_REGION": "us-west-2"
}
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"bedrock-image": {
"command": "uvx",
"args": ["mcp-server-bedrock-image"],
"env": {
"AWS_REGION": "us-west-2"
}
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"bedrock-image": {
"command": "uvx",
"args": ["mcp-server-bedrock-image"],
"env": {
"AWS_REGION": "us-west-2"
}
}
}
}Variable | Default | Description |
|
| AWS region for Bedrock |
|
| Auth mode: |
| — | Bedrock API key (bearer mode only) |
| Auto from region | Override Bedrock runtime endpoint |
|
| Where to save generated images |
|
| Save JSON metadata alongside images |
See .env.example for a template.
Once connected, ask your AI agent naturally:
"Generate a hero image of a modern hotel lobby with warm lighting in 16:9"
"Remove the background from this product photo"
"Apply the style of this watercolor painting to the room photo"
"Add our logo to the generated image in the least busy corner"
Or call tools directly:
# Generate
generate_image(prompt="Modern hotel lobby with warm lighting", aspect_ratio="16:9")
# Edit
remove_background(image_path="/path/to/photo.png")
style_transfer(prompt="Watercolor style", image_path="room.png", style_image_path="ref.png")
search_and_replace(image_path="scene.png", prompt="red chair", search_prompt="blue chair")
outpaint(image_path="photo.png", prompt="extend the garden", right=200, bottom=100)
# Upscale
upscale_fast(image_path="/path/to/small.png")
upscale_creative(image_path="photo.png", prompt="enhance details, sharp textures")
# Brand
compose_branded(image_path="hero.png", logo_path="logo.png", output_path="branded.png")compose_branded worksThe composition-aware branding tool doesn't use Bedrock — it runs locally with Pillow. It divides the image into a 3x3 grid, scores each quadrant by visual complexity (standard deviation of grayscale values), and places the logo in the least complex region. It also auto-selects between light and dark logo variants based on the background brightness.
src/mcp_server_bedrock_image/
├── server.py # FastMCP server — registers all 10 tools
├── config.py # Environment variables and model IDs
├── bedrock_client.py # Dual-auth Bedrock client (boto3 + bearer)
├── image_utils.py # Image save and metadata utilities
└── tools/
├── generate.py # Text-to-image generation
├── edit.py # Background removal, style transfer, recolor, outpaint, search-replace
├── upscale.py # Fast and creative upscaling
└── compose.py # Composition-aware logo placement# Clone and install
git clone https://github.com/Yaksh36/mcp-server-bedrock-image.git
cd mcp-server-bedrock-image
uv sync --all-extras --dev
# Run tests
uv run pytest -v
# Lint and format
uv run ruff check src/ tests/
uv run ruff format src/ tests/Contributions are welcome. Please:
Fork the repo and create a feature branch
Add tests for new functionality
Ensure uv run pytest -v and uv run ruff check src/ tests/ pass
Open a pull request
Overlay logo with composition-aware placement.
| Name | Required | Description | Default |
|---|---|---|---|
| logo_path | Yes | Path to the logo file (RGBA PNG) | |
| image_path | Yes | Path to the source image | |
| logo_scale | No | Logo size as fraction of image width | |
| output_path | Yes | Where to save the branded image | |
| logo_variant | No | 'light', 'dark', or 'auto' | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It only states the action without detailing effects, requirements, output behavior, or side effects. It does not mention that a new file is created, whether the source is modified, or how composition-aware placement is determined.
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 extraneous words, making it highly concise. However, it is under-specified, trading substance for brevity, so it loses a point for not earning its place with more useful detail.
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 5 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain composition-aware logic, parameter behaviors, or expected output, making it inadequate for an agent to invoke 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 coverage is 100%, so the baseline is 3. The description's phrase 'composition-aware placement' hints at how logo_scale and logo_variant might interact, but it doesn't formally explain parameters beyond what the schema already provides, so no additional credit is warranted.
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 'Overlay' with the object 'logo' and qualifies with 'composition-aware placement', which distinguishes it from sibling tools. However, it doesn't elaborate on what composition-aware entails, so it's clear but not fully detailed.
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?
There is no guidance on when to use this tool versus alternatives like generate_image or style_transfer, nor any mention of prerequisites or exclusions. The description leaves the usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a high-quality image using Stable Image Ultra on Bedrock.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Seed for reproducibility | |
| prompt | Yes | Text description of the image to generate (max 10000 chars) | |
| filename | No | Output filename without extension | |
| output_dir | No | Override output directory | |
| aspect_ratio | No | Aspect ratio, e.g. '16:9', '1:1', '9:16' | |
| negative_prompt | No | What to exclude from the image |
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 reveals the underlying model but does not disclose side effects (e.g., file output), return format, rate limits, or safety characteristics.
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, efficient sentence that is easy to parse. It could be more informative, but it avoids unnecessary verbosity.
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?
With no output schema and 6 parameters, the description is under-specified. It does not explain the output file behavior, how to determine the result, or how this tool fits among its many siblings. The lack of annotations and return-value documentation leaves significant gaps.
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 does not add any parameter-specific semantics beyond what the schema already provides.
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 action ('Generate a high-quality image') and identifies the specific model ('Stable Image Ultra on Bedrock'). However, it does not distinguish this tool from the sibling tool 'generate_image_core' or other image-manipulation 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?
No guidance is provided on when to use this tool versus alternatives like generate_image_core, style_transfer, or upscale_fast. There is no mention of exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image using Stable Image Core (faster, lower cost).
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Seed | |
| prompt | Yes | Text description of the image to generate | |
| filename | No | Output filename | |
| output_dir | No | Override output directory | |
| aspect_ratio | No | Aspect ratio | |
| negative_prompt | No | What to exclude |
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 only mentions the model and cost/speed characteristics, omitting any detail about output behavior, file saving, side effects, or limitations.
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 sentence with no redundant words. It conveys the core purpose and key differentiator efficiently.
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 has 6 parameters, no output schema, and no annotations, the description is too sparse to be contextually complete. It does not explain what the tool returns, where images are saved, or any prerequisites.
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 schema covers all 6 parameters with descriptions (100% coverage), so the baseline is 3. The description itself adds no parameter semantics, leaving the schema to do 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 uses a specific verb ('Generate') and resource ('Stable Image Core'), and the parenthetical '(faster, lower cost)' differentiates it from sibling tools like generate_image. The tool's role is immediately clear.
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 parenthetical '(faster, lower cost)' implies use when speed or budget is a priority, but the description does not explicitly name alternatives or state when not to use this tool. Usage guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend an image in any direction while maintaining visual consistency.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Pixels to extend top | |
| left | No | Pixels to extend left | |
| right | No | Pixels to extend right | |
| bottom | No | Pixels to extend bottom | |
| prompt | Yes | Description for the extended area | |
| filename | No | Output filename | |
| image_path | Yes | Path to the image file | |
| output_dir | No | Override output directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only mentions 'maintaining visual consistency' as a quality, but says nothing about side effects, whether the original image is modified, output file handling, or any limitations. This is too minimal to understand the tool's behavior.
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, efficient sentence that is front-loaded with the key action. It is concise and contains no filler, though it may be slightly under-sized for a tool with many parameters, the wording itself is well-structured.
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 tool has 8 parameters, no output schema, and no annotations, yet the description provides no context about return values, side effects, or operational details. It is incomplete for a tool of this complexity, leaving the agent without crucial information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full documentation for all 8 parameters with descriptions, so the schema already covers parameter semantics. The description adds no extra meaning beyond what the schema provides, hence a baseline score of 3.
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: 'Extend an image in any direction while maintaining visual consistency.' This is a specific verb+resource combination that distinguishes outpaint from sibling tools like upscale or style transfer.
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?
No when-to-use or alternative guidance is provided. The description merely states what the tool does, leaving the agent to infer when to choose it over other image manipulation tools. It does not mention exclusions or contexts where another tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove the background from an image.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Output filename | |
| image_path | Yes | Path to the image file | |
| output_dir | No | Override output directory |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It does not mention output format, file handling, side effects, or whether the original image is modified.
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, focused sentence that conveys the core purpose with zero 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?
The description is too minimal for a tool that processes images and likely returns a file. It lacks any explanation of return value or outputs, and no output schema exists to compensate.
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% with descriptions for all three parameters. The tool description adds no additional parameter context, but the baseline holds since the schema fully documents each parameter.
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 with a specific verb ('Remove') and resource ('background from an image'), distinguishing it from siblings like generate_image or style_transfer.
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?
No guidance is provided on when to use this tool over alternatives, nor any prerequisites or exclusions. The description does not name sibling tools or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recolor specific elements in an image.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Description of the scene | |
| filename | No | Output filename | |
| image_path | Yes | Path to the image file | |
| output_dir | No | Override output directory | |
| select_prompt | Yes | What to select for recoloring | |
| recolor_prompt | Yes | New color/appearance for the selected element |
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 only states the action without revealing whether a new file is created, how output paths are handled, or any side effects. This is a significant gap for a tool that modifies images.
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, direct sentence with no redundant wording. It front-loads the core action and resource, making it instantly scannable. Appropriately concise for the information it provides.
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 tool has 6 parameters and no output schema, yet the description is only one sentence. It fails to explain how the prompts interact, what the output is, or when to use this tool, leaving much of the context to be inferred. For a tool of this complexity, a richer description is needed.
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%, and each parameter has a clear description (e.g., 'What to select for recoloring' for select_prompt). The tool description adds no extra parameter semantics, so the baseline score of 3 applies.
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 'Recolor specific elements in an image.' states a specific action (recolor) and a clear resource (specific elements in an image), which distinguishes it from sibling tools like search_and_replace. It could be more explicit about how elements are selected, but the core purpose is clear.
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 no guidance on when to use this tool versus alternatives such as style_transfer or search_and_replace. It does not mention exclusions, prerequisites, or typical scenarios, leaving the agent to infer usage from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace objects or elements in an image.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | What to replace with | |
| filename | No | Output filename | |
| image_path | Yes | Path to the image file | |
| output_dir | No | Override output directory | |
| search_prompt | Yes | What to find and replace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry all behavioral disclosure. It only restates the high-level operation without explaining how the replacement works, whether it requires certain inputs, what happens to the original elements, or what the output looks like. This is a significant gap.
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 concise sentence with no redundancy. It is efficiently structured, though the brevity contributes to under-specification in other dimensions.
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 tool with 5 parameters, no output schema, and no annotations, a one-line description is severely incomplete. It fails to explain the role of 'search_prompt', output handling, or expected behavior, making it difficult for an agent to invoke 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?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional parameter meaning beyond what the schema already provides, so it neither helps nor hurts.
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 ('Replace') and the target ('objects or elements in an image'), making the tool's basic purpose understandable. It does not explicitly differentiate from sibling tools like 'search_and_recolor', but the verb 'replace' vs 'recolor' separates them conceptually.
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?
No guidance is provided on when to use this tool versus alternatives such as 'search_and_recolor' or 'generate_image'. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply the style of a reference image to a source image.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Description of desired output | |
| filename | No | Output filename | |
| image_path | Yes | Path to the source image | |
| output_dir | No | Override output directory | |
| negative_prompt | No | What to exclude | |
| style_image_path | Yes | Path to the style reference image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the operation is destructive, whether a new file is created, what output format to expect, or any side effects. The single sentence offers minimal behavioral insight.
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, clear sentence that is appropriately front-loaded and easy to read. It wastes no words, though it is terse to the point of under-specification.
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 tool with 6 parameters, no annotations, and no output schema, the description is far too sparse. It fails to explain the output behavior, prerequisites, or how it fits among the many sibling image-editing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds only a slight mapping between 'reference image' and 'style_image_path' and 'source image' to 'image_path', but this adds no new semantic value.
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 applies a reference image's style to a source image, which is a specific verb+resource combination. It is distinct from siblings like remove_background or generate_image, though it does not explicitly differentiate them.
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?
No guidance is provided on when to use this tool versus alternatives like generate_image or search_and_replace. There are no exclusions, prerequisites, or context indicating preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creatively upscale image up to 4K resolution.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Description to guide creative upscaling | |
| filename | No | Output filename | |
| image_path | Yes | Path to the image file | |
| output_dir | No | Override output directory | |
| negative_prompt | No | What to exclude |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior itself. It only states that the image is upscaled creatively, but fails to clarify what 'creative' entails, how the required prompt influences the output, whether the process is generative or deterministic, or any side effects. A single sentence is insufficient for a tool with no annotation support.
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?
One concise, front-loaded sentence contains all the essential information without redundancy. It is appropriately sized for the tool's purpose and uses every word effectively.
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 has five parameters, no output schema, and no annotations, the description is severely under-specified. It does not explain the creative upscaling mechanism, how the prompt and negative prompt affect output, or what the user should expect in return. An agent would need additional context to correctly invoke this tool in varied scenarios.
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 schema already documents all five parameters with clear descriptions, yielding 100% schema coverage, so the baseline is 3. The tool description adds no parameter-specific meaning beyond the schema; it does not explain how the prompt guides creative upscaling or the role of negative_prompt, but does not need to due to complete schema coverage.
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 'upscale' with the object 'image', specifies the creative style, and defines the target resolution 'up to 4K'. This uniquely distinguishes it from sibling tools like 'upscale_fast', which implies a non-creative upping operation.
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 word 'creatively' implies this tool is for aesthetic or imaginative upscaling, but the description provides no explicit guidance on when to choose this over 'upscale_fast' or other siblings. It does not name alternatives or exclusion criteria, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upscale image resolution by 4x.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Output filename | |
| image_path | Yes | Path to the image file | |
| output_dir | No | Override output directory |
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 only states the 4x upscale action and does not disclose output behavior, file handling, potential side effects, or what 'fast' implies. This is insufficient for a tool with zero annotation 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 description is a single, front-loaded sentence with zero wasted words, efficiently conveying the core action. It earns its place without unnecessary elaboration.
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 being a simple tool, the absence of annotations and output schema means the description should explain return values or output behavior. It only states the upscale factor, omitting what the tool returns or where the output goes, leaving the agent to guess from parameter names.
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%, with each parameter having a basic description (image_path, filename, output_dir). The tool description adds no parameter-level meaning beyond what the schema already provides, so 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 'Upscale image resolution by 4x.' clearly states the tool's function with a specific verb and resource, plus the upscale factor. However, it does not explicitly differentiate itself from the sibling tool 'upscale_creative', leaving the distinction between 'fast' and 'creative' upscaling implicit.
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 no guidance on when to use this tool versus alternatives such as 'upscale_creative' or other siblings. There is no mention of context, prerequisites, or exclusions, so the agent receives no usage direction beyond the tool's name.
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.0compose_brandedgenerate_imagegenerate_image_coreoutpaintremove_backgroundsearch_and_recolorsearch_and_replacestyle_transferupscale_creativeupscale_fastScored across 10 tools
Each tool targets a distinct image operation: generation, editing, style transfer, upscaling, etc. The two generation tools are clearly differentiated by model (Ultra vs Core) and trade-off (quality vs speed), so there is no real ambiguity.
Most names follow a verb_noun or verb_adverb pattern in snake_case (e.g., generate_image, remove_background, upscale_fast). 'outpaint' is a slight deviation as a single verb, but it's still intuitive and consistent with the action-oriented style.
With 10 tools, the server is well-scoped for an image generation/editing toolkit. Each tool covers a separate capability with no unnecessary redundancy, making the count feel justified and manageable.
The toolkit covers the core image lifecycle: generation, editing (style, recolor, replace, background removal), extension (outpaint), enhancement (upscaling), and branding (compose_branded). No critical gaps are apparent for its intended purpose.
MCP server for NanoBanana AI image generation and editing
An MCP server that integrates with Discord to provide AI-powered features.
MCP server for Qwen Image 3 AI image generation
MCP server for Flux AI image generation