Click on "Install 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., "@Midjourney Best Experience MCP Server Generate a futuristic cyberpunk city at sunset --ar 16:9"
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.
用于访问 Midjourney Best Experience API 的 MCP 服务器。
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-midjourney_best_experience）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: openai-gpt-image-mcp
这是一个 MCP 服务器，用于访问 Midjourney Best Experience API。
PyPI 包名: bach-midjourney_best_experience
版本: 1.0.0
传输协议: stdio
pip install bach-midjourney_best_experiencepip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-midjourney_best_experience bach_midjourney_best_experience
# 或指定版本
uvx --from bach-midjourney_best_experience@latest bach_midjourney_best_experiencepython server.py# 安装
pip install bach-midjourney_best_experience
# 运行（命令名使用下划线）
bach_midjourney_best_experience此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:
{
"mcpServers": {
"bach-midjourney_best_experience": {
"command": "uvx",
"args": ["--from", "bach-midjourney_best_experience", "bach_midjourney_best_experience"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"bach-midjourney_best_experience": {
"command": "uvx",
"args": ["--from", "bach-midjourney_best_experience", "bach_midjourney_best_experience"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}此服务器提供以下工具:
action_relaxuu0026vDo the relax action - You can perform upsample (same as the UI, U2...), variation (V1, V2...), zoom out 1.5x, zoom out 2x, pan, and other operations on the images generated in the first step
端点: POST /mj/action-relax
参数:
action (string) 必需: the action is the enumeration values returned in the action list in the callback
image_id (string) 必需: the params image_id in the relax job callback or task_id eg: 9c4410a2-2bb4-2428-b0e4-0a3b41f48e3b
hook_url (string): if set will notify the result to your hook_url
action_fastuu0026vDo the fast action - You can perform upsample (same as the UI, U2...), variation (V1, V2...), zoom out 1.5x, zoom out 2x, pan, and other operations on the images generated in the first step
端点: POST /mj/action-fast
参数:
action (string) 必需: the action is the enumeration values returned in the action list in the callback
image_id (string) 必需: the params image_id in the fast job callback or task_id eg: 6a028074-884e-7840-2ef4-715a5ab3b6c7
hook_url (string): Example value: https://www.google.com
generate_relaxgenerate the images relax Generate queue asynchronous notifications to hook_ url, overall generation time is Depends on account status and task queuing
端点: POST /mj/generate-relax
参数:
prompt (string) 必需: Example value: a beautiful cat --ar 1920:1080
hook_url (string): if set will notify the result to your hook_url
generate_fastgenerate the images fast Generate queue asynchronous notifications to hook_ url, overall generation time is around 40-60s
端点: POST /mj/generate-fast
参数:
prompt (string) 必需: Example value: a beautiful cat --ar 1920:1080
hook_url (string): if set will notify the result to your hook_url
get_job_by_task_idyou can get the generate job and action job status by the task_id, and the task_id will expired at 24 hours after
端点: GET /mj/get-task-id
参数:
task_id (string) 必需: Example value: 6ddd8121-2ae4-af61-b73d-eaefc8318d09
传输协议: stdio
HTTP 客户端: httpx
MIT License - 详见 LICENSE 文件。
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
Do the fast action - You can perform upsample (same as the UI, U2...), variation (V1, V2...), zoom out 1.5x, zoom out 2x, pan, and other operations on the images generated in the first step
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | the action is the enumeration values returned in the action list in the callback | |
| image_id | Yes | the params image_id in the fast job callback or task_id eg: 6a028074-884e-7840-2ef4-715a5ab3b6c7 | |
| hook_url | No | Example value: https://www.google.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only lists operation types without disclosing behavior such as mutation, idempotency, rate limits, or error handling. The 'fast' in the name implies performance but is not explained.
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 but slightly repetitive ('Do the fast action' followed by 'You can perform...'). It is not excessively long but could be more concise and 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?
Given no output schema, no annotations, and 3 parameters, the description leaves gaps: no return value info, prerequisites, error handling, or explanation of the garbled tool name. It is insufficient for full 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 coverage is 100%, so baseline is 3. The description adds value for 'image_id' by clarifying its source, and for 'action' by example enumeration values, but does not fully specify the enumeration or validate constraints.
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 it performs operations like upsample, variation, zoom out, and pan on generated images, which provides a clear purpose. However, the tool name is garbled and the description is slightly repetitive, lacking differentiation from sibling actions.
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 explicit guidance on when to use this tool versus alternatives like action_relaxuu0026v or generate tools. The description only mentions it applies to images from the first step, but does not specify conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Do the relax action - You can perform upsample (same as the UI, U2...), variation (V1, V2...), zoom out 1.5x, zoom out 2x, pan, and other operations on the images generated in the first step
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | the action is the enumeration values returned in the action list in the callback | |
| image_id | Yes | the params image_id in the relax job callback or task_id eg: 9c4410a2-2bb4-2428-b0e4-0a3b41f48e3b | |
| hook_url | No | if set will notify the result to your hook_url |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It lists operations but fails to mention side effects (e.g., whether actions are destructive), prerequisites (e.g., image must exist), or constraints (e.g., action values come from callback). Vague 'other operations' adds uncertainty.
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?
Short description but the opening line is redundant. The bullet-like list is somewhat structured, but not optimally concise. Every sentence earns its place, though the first could be refined.
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 (mutating actions, reliance on callback values), the description lacks workflow context: it doesn't explain that 'action' must come from a prior callback response, nor that 'image_id' refers to a previously generated image. Output schema is absent, so description should cover return behavior, but it does not.
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 covers all parameters with descriptions (100% coverage). The description adds no extra meaning beyond the schema for 'action', 'image_id', or 'hook_url'. 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 states it performs relax actions like upsample, variation, zoom, pan on images from the first step, but the opening 'Do the relax action' is vague and tautological. It differentiates from sibling 'action_fast' by mentioning relax, but not explicitly.
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 on when to use this tool versus 'action_fast' or 'generate_relax'. Does not specify that it is for post-generation actions on relax-generated images, leaving the agent unclear about workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate the images fast Generate queue asynchronous notifications to hook_ url, overall generation time is around 40-60s
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Example value: a beautiful cat --ar 1920:1080 | |
| hook_url | No | if set will notify the result to your hook_url |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses asynchronous notification via hook_url and a generation time estimate (40-60s), which adds useful behavioral context. However, it does not describe what happens if hook_url is omitted, the return format, or potential side effects, limiting completeness.
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 concise, consisting of two short sentences, but it suffers from formatting issues like double spaces and a missing underscore in 'hook_ url'. It communicates the core idea efficiently but lacks polish and clear structure.
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 two parameters, no output schema, and no annotations, the description omits important context. It does not explain how to retrieve results (a sibling tool 'get_job_by_task_id' suggests job tracking), nor does it clarify differences with similar tools like 'generate_relax'. The missing details compromise completeness for effective agent 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 the baseline is 3. The description marginally adds value by mentioning 'asynchronous notifications to hook_ url' and the generation time, which relates to the prompt parameter. However, it does not significantly enhance parameter semantics beyond what the schema already provides for both 'prompt' and 'hook_url'.
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 'generate the images fast' and provides an estimated generation time (40-60s), clearly indicating the tool's purpose of fast image generation with a specific speed benchmark. However, it does not differentiate from sibling tools like 'generate_relax' or 'action_fast', which are likely similar but with different speed or action contexts.
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 does not provide any guidance on when to use this tool versus alternatives. No explicit when-to-use or when-not-to-use information is given, leaving the AI agent to infer usage from the name and brief description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate the images relax Generate queue asynchronous notifications to hook_ url, overall generation time is Depends on account status and task queuing
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Example value: a beautiful cat --ar 1920:1080 | |
| hook_url | No | if set will notify the result to your hook_url |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions that generation time depends on account status and queuing, which gives some insight, but it does not state that the tool is non-destructive, whether it requires special permissions, or what happens to the result beyond the hook_url notification.
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 short but poorly structured and contains grammatical errors ('generate the images relax Generate queue asynchronous notifications'). It is not well-written and lacks clarity, which hinders conciseness.
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 lack of output schema and annotations, the description should provide more context. It mentions async notification to hook_url but does not explain the response format, what 'relax' mode entails compared to siblings, or any other behavioral boundaries. The description is incomplete for a tool with two parameters and no other structured support.
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 input schema already documents both parameters adequately. The description does not add any additional semantic value beyond what is in the schema, so 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 states 'generate the images relax' indicating a verb and resource, but the phrasing is garbled and confusing. The core purpose of generating images in relax mode is discernible, but the statement is not clear, especially with the merged words 'images relax Generate'.
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 siblings like 'generate_fast' or 'action_relaxuu0026v'. There is no mention of context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
you can get the generate job and action job status by the task_id, and the task_id will expired at 24 hours after
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Example value: 6ddd8121-2ae4-af61-b73d-eaefc8318d09 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions task_id expiration after 24 hours; lacks other behavioral details like response format or error handling.
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?
Single sentence is concise but contains grammatical issues and run-on structure; could be clearer.
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?
Missing return value description and error handling details; for a simple retrieval tool, the description is incomplete given no output schema.
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 covers the single parameter fully with example; description adds no additional meaning beyond stating its purpose, meeting the baseline for high 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 tool retrieves status for generate and action jobs using a task_id, distinguishing it from sibling tools which seem to initiate jobs.
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 explicit guidance on when to use this tool versus alternatives; usage context is only implied by the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are mostly distinct by mode (fast vs relax) and purpose (generate vs action vs status), but the 'action_fastuu0026v' and 'action_relaxuu0026v' have confusing suffixes that could cause ambiguity.
Naming pattern is inconsistent: 'generate_fast' and 'generate_relax' use underscore, while 'action_fastuu0026v' and 'action_relaxuu0026v' append a cryptic suffix. 'get_job_by_task_id' follows a different verb_noun pattern.
With 5 tools, the server is well-scoped for its purpose of image generation and manipulation. Each tool covers a distinct aspect: fast/relax generation, corresponding actions, and status checking.
The set covers the core workflow: generate (fast/relax), apply actions (upsample, variation, zoom), and check status. A minor gap is the lack of a tool to directly retrieve the generated image URL, but status likely provides this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Midjourney AI image generation and editing
MCP server for Qwen Image 3 AI image generation
MCP server for Flux AI image generation
MCP server for NanoBanana AI image generation and editing
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/bachai-midjourney-best-experience'
If you have feedback or need assistance with the MCP directory API, please join our Discord server