MidjourneyMCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.9
Disambiguation5/5
Each tool has a clearly distinct purpose: generation (imagine, blend, with_reference), editing (edit, transform), video (generate_video, extend_video), analysis (describe, shorten, translate), and task management. No significant overlap; descriptions clearly differentiate them.
Naming Consistency5/5
All tools follow a consistent 'midjourney_' prefix plus verb or verb_noun pattern (e.g., midjourney_blend, midjourney_get_task). Naming is systematic and predictable.
Tool Count5/5
With 16 tools covering generation, editing, video, analysis, and task management, the count is well-scoped for Midjourney's capabilities. Each tool serves a distinct function without redundancy.
Completeness5/5
The tool surface covers the full creative workflow: image generation, blending, editing, transformation, video creation, prompt analysis, translation, task tracking, and reference guides. No obvious gaps for the intended purpose.
Average 4.2/5 across 16 of 16 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states that it blends images and returns a Task ID, implying asynchronous generation. It does not disclose side effects, resource consumption, authentication needs, or other behavioral traits, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose, usage list, example, and return type. It is front-loaded with the main action. Some redundancy exists (e.g., repeating 'blend' and 'combine'), but overall it's well-organized and no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and comprehensive parameter documentation, the description covers the tool's purpose, usage scenarios, and return value. It could be more complete by mentioning limitations like image size or format, but it sufficiently sets expectations for a blending tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing full parameter descriptions. The tool description adds an example but does not provide additional semantics beyond the schema. With high schema coverage, the baseline of 3 is appropriate for not adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool blends multiple images (2-5) using Midjourney, which is a specific verb+resource. It distinguishes from siblings like midjourney_imagine (text-to-image) by focusing on image blending, though it doesn't explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use this when' bullet points covering merging, composite creation, and style blending. It gives clear context but does not mention when not to use or suggest alternative tools among the siblings, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes actions and their effects, but lacks details on side effects, rate limits, or prerequisites like image_id validity. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a brief purpose statement, bullet points for usage, a workflow example, and return info. No unnecessary words; efficiently conveys needed information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, many actions) and existence of an output schema, the description covers main usage scenarios and workflow. Could improve by noting error handling or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context: image_id is tied to a previous generation, prompt/mask are used with variation_region, and the workflow example explains action sequence. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool transforms existing Midjourney images with operations like upscaling, variations, zoom, and pan. It distinguishes itself from generation tools but does not explicitly differentiate from midjourney_edit or midjourney_blend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this when' section lists specific scenarios (upscale, variation, zoom, pan, reroll), and a workflow example is provided. However, it does not explicitly state when not to use this tool or mention alternatives like blend or edit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explains the core behavior ('adding more frames based on your prompt description') and return value ('Task ID and extended video information including new video URLs'). However, it omits potential caveats such as processing time, cost, or whether the original video is modified, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient: a one-sentence purpose, a brief explanatory clause, 'Use this when' bullets, and a 'Returns' line. It is front-loaded with the essential action and contains no filler, earning a maximum score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and rich input/output schemas, the description covers the essential context: what it does, when to use it, and what it returns. The 'Returns' section adds a helpful summary even though an output schema exists. It could benefit from mentioning async behavior or limitations, but it is sufficiently complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters have full schema descriptions, so the baseline is 3. The description reinforces that 'prompt' guides the extension and 'video_id' refers to a previous generation, which aligns with the schema. It does not add significant new meaning beyond what the schema already provides, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 existing Midjourney video to make it longer.' The verb 'extend' and resource 'video' are specific, and it distinguishes itself from sibling tools like midjourney_generate_video (which creates new videos) by focusing on extending a previously generated video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this when' section lists three clear scenarios (making a video longer, continuing story/motion, adding content to a short clip), which guides appropriate use. However, it does not explicitly mention alternatives or when not to use this tool, so it falls slightly short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It states the tool queries and retrieves but does not disclose any potential side effects, rate limits, or idempotency. For a query tool, this is adequate but lacks depth on constraints or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence for purpose, a bulleted list of usage scenarios, and a returns summary. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter descriptions, the description covers purpose, usage, and key return fields (URLs, dimensions, actions). It lacks mention of idempotency or multiplicity but is complete for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (task_id, trace_id) already well-described in the schema. The tool description adds no new meaning beyond summarizing their purpose. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries the status and result of a Midjourney generation task. It specifies retrieving image/video URLs and metadata, and distinguishes this from siblings like midjourney_imagine (creation) and midjourney_get_tasks_batch (batch query).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Four explicit 'Use this when' scenarios are provided (check completion, retrieve URLs, get full details, async results). It does not mention when not to use it or direct alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that generation returns 4 video variations, requires a reference image, and optionally allows an end frame. It does not mention rate limits or auth, but covers key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with bullet points for use cases and a clear returns section. It is well-structured without being verbose, though some redundancy exists with the returns section repeating output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and video generation complexity, the description covers purpose, required inputs, and output. It lacks details on error handling or processing time but is sufficient for an agent to decide when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 context about image_url being required and generation constraints, but the schema already provides good descriptions. The additional value is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates a video from a reference image using Midjourney, specifying it is image-to-video only, which distinguishes it from potential text-to-video tools and from sibling tools like midjourney_extend_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use this when:' scenarios covering animation, short clips, and AI video generation. It contrasts with the image-to-video requirement but does not name specific alternatives for different use cases (e.g., text-to-video), though no such sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It states it returns detailed list and usage guidance, implying a read-only operation. However, it does not explicitly confirm no side effects or mention authentication, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each providing essential information: purpose, context as reference guide, and content of return. No unnecessary words, front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description is complete. It explains what the tool does and what the return entails, sufficient for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, baseline is 4. The description adds value by explaining the output includes 'Detailed list of all transformation actions and when to use them,' which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available transformation actions for Midjourney images,' specifying 'transformation' to distinguish from sibling tools like midjourney_list_actions. The title reinforces this, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it's a 'Reference guide for transform actions used with midjourney_transform tool,' implying it should be used before calling midjourney_transform. However, it does not explicitly state when to use or not use this tool compared to alternatives like midjourney_list_actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes the process (analyzes tokens, produces candidates) but lacks details on side effects, permissions, rate limits, or whether the tool is read-only. The description is informative but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief main sentence, a clarifying paragraph, a bulleted use-case list, and a return statement. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, clear output) and the presence of an output schema, the description covers all essential aspects: what it does, when to use it, and what it returns. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already well-documented. The description adds some context about the analyzer and token weighting, but this does not significantly increase understanding beyond the schema's own description. The baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'shorten and analyze' and the resource 'Midjourney prompt'. It distinguishes itself from siblings like midjourney_imagine or midjourney_describe by focusing on prompt optimization, and it explicitly lists the output (up to 5 shortened candidates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'Use this when:' section with three specific scenarios (long prompt, identifying impactful words, simplifying complex prompts). However, it does not mention when not to use the tool or explicitly name alternative siblings, which would strengthen the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains mask semantics (white=regenerate, black=preserve) and states return type (Task ID and image info). However, it does not disclose potential side effects, authentication needs, or safety aspects like overwriting originals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main paragraph, bullet list for usage, mask instructions, and return info. Each sentence is informative and concise without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (2 required) and an output schema, the description covers core functionality and mask usage. It lacks explanations for 'mode' (fast/relax/turbo) and 'callback_url', but these are documented in the schema. Return values are mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 by explaining mask semantics (white/black areas) and providing prompt examples, which goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit an existing image using Midjourney' and specifies modification via text prompt and optional mask. This differentiates it from sibling tools like midjourney_imagine (generation) and midjourney_transform (style transfer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The bullet list explicitly states when to use the tool: modify existing image, add/change elements, style changes, edit with mask. It does not mention when not to use or list alternatives, but provides clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the 2x2 grid of 4 variations and the return payload of Task ID, URLs, dimensions, and available actions. However, it does not mention asynchronous behavior, failures, rate limits, or authorization requirements, which matters for a generation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear opening statement, bulleted usage guidance, an alternative-tool note, and a returns section. Every sentence adds value and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 11 parameters, rich schema descriptions, and output schema, the tool description is reasonably complete. It covers purpose, usage context, alternatives, and return information. It could add more detail about asynchronous behavior or version quirks, but those are largely covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description itself does not explain individual parameters, but schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The baseline of 3 applies because the schema handles the semantic burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Generate AI images from a text prompt using Midjourney' and calls itself 'the primary way to create images', providing a specific verb and resource. It also distinguishes itself from sibling tools by noting that transformations should use midjourney_transform instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear 'Use this when' bullet list and explicitly directs users to midjourney_transform for image transformations like upscaling or variations. This gives strong context for when to use this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses the tool analyzes an image and returns descriptions with style tags. No side effects are mentioned, but the read-only nature is implied. Could explicitly state non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a summary, bullet-point usage, and output note. Every sentence adds value, no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 an output schema, the description covers purpose, usage, and return format completely. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for image_url (must be direct URL). The tool description adds no additional parameter guidance, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides AI-generated descriptions of an image, returning 4 alternative text prompts. This distinguishes it from sibling tools like midjourney_imagine (generation) and midjourney_transform (editing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists specific use cases (e.g., reverse-engineering style, inspiration) but does not explicitly state when not to use or compare to alternatives. Still provides clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that translation is optimized for image generation and returns English text ready as a prompt. This is adequate for a straightforward translation tool, though it does not mention any rate limits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short paragraphs plus a return line, breaking down purpose, usage, and output. Every sentence is meaningful, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (single parameter, output schema exists), the description covers purpose, when to use, and what it returns. It is fully complete for an agent to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, giving a baseline of 3. The description adds minimal extra value beyond the schema, only rephrasing that the content is Chinese text for translation. The schema already describes the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool translates Chinese text to English specifically for Midjourney prompts, with a specific verb 'Translate' and resource 'Chinese text to English'. It distinguishes itself from siblings which are all other Midjourney tool categories (e.g., imagine, blend) that serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear list of when to use the tool (Chinese description needing translation, converting Chinese prompts, needing English for better results). While no explicit when-not or alternatives are given, the context of Midjourney tools makes it clear that this is for translation only, not other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the tool uses a reference image and modifies based on prompt, mentions the --iw parameter, and states it returns a Task ID and image info. Missing: behavior on invalid URLs, rate limits, or cost differences. Still good overall.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with clear sections: main action, usage scenarios, tips. Every sentence adds value. No redundant or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no nested objects, and an output schema (implied), the description is sufficient. It covers usage, returns, and tips. Could elaborate on output fields, but output schema exists to fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond schema by explaining how to use --iw for control and providing example prompts. This contextualizes the prompt parameter more richly than the schema description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates images using a reference image as inspiration. The verb 'generate' and the resource 'reference image' are specific, and it contrasts with sibling tools like 'midjourney_imagine' which does not use a reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists explicit use cases ('when you want to reimagine, change style, add/change elements'). However, it does not explicitly state when NOT to use this tool (e.g., for generation without reference). This is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains what a seed is and its role in reproducibility, and states the return value. It could mention that the operation is read-only and requires prior generation, but overall it's transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with six well-structured sentences. Use cases are presented in a bullet-like format without redundancy, and every sentence contributes meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no nested objects, output schema present), the description fully covers the needed context: purpose, usage scenarios, parameter meaning, and return value. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 by clarifying 'image_id' as the field from a previous imagine result, which helps the agent understand the specific parameter context beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('seed value of a previously generated Midjourney image'), making the tool's purpose unambiguous. It distinguishes from sibling tools like midjourney_imagine which generates images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (reproduce generation, use with --seed, create variations) but does not specify when not to use or mention alternative tools for similar tasks. It gives clear context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the query behavior, mentions pagination, and max batch size in schema, but does not disclose rate limits, authentication needs, or behavior for invalid IDs. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a clear header and bullet-pointed usage scenarios. Every sentence adds value, no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 0 required, high schema coverage, and output schema), the description covers purpose, usage, return value ('Status and result information'), and pagination. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. The description adds value by explaining when to omit task_ids/trace_ids for pagination, and the schema includes max batch recommendation. This goes beyond baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries multiple Midjourney tasks at once, specifying action (query), resource (tasks), and batching. It distinguishes itself from the sibling tool midjourney_get_task by emphasizing efficiency and batch capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists four use cases with bullet points, guiding when to use this tool (multiple pending checks, batch status, pagination). It implies alternatives (single task queries use midjourney_get_task) without explicitly naming it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states it returns a categorized list of actions and tools, which is a read-only operation. No hidden behaviors or side effects are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the primary purpose, then additional context. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists, and it is a simple listing tool, the description fully covers what the tool does and what it returns. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The description adds value by describing the output format (categorized list) and its purpose as a reference guide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that the tool lists all available Midjourney API actions and corresponding tools, and serves as a reference guide. This clearly distinguishes it from sibling tools which are action-specific (e.g., midjourney_imagine, midjourney_transform).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is helpful for understanding the full capabilities, implying use for discovery and reference. It does not explicitly state when not to use it or compare to alternatives, but context makes it clear this is the overview tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it returns a guide with prompt structure, parameters, and examples. It is a read-only operation with no side effects, and the return content is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: purpose, benefit, and return content. It is well-structured with no unnecessary fluff, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description covers the tool's purpose and return content completely. It leaves no gaps in understanding what the tool does and what it provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is trivially 100%. The description adds no parameter information, but since none exist, the baseline score of 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get guidance on writing effective prompts for Midjourney,' which identifies the tool's purpose with a specific verb and resource. It distinguishes from sibling tools like 'midjourney_imagine' by focusing on guidance rather than generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the guide does and implies usage before writing prompts, saying 'Following this guide helps Midjourney understand your creative vision.' However, it does not explicitly mention when not to use it or provide alternatives, though this is minimally necessary for a guide tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MidjourneyMCP MCP server](https://glama.ai/mcp/servers/AceDataCloud/MidjourneyMCP/badges/card.svg)](https://glama.ai/mcp/servers/AceDataCloud/MidjourneyMCP)

Score Badge

Copy to your README.md:

[![MidjourneyMCP MCP server](https://glama.ai/mcp/servers/AceDataCloud/MidjourneyMCP/badges/score.svg)](https://glama.ai/mcp/servers/AceDataCloud/MidjourneyMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AceDataCloud/MidjourneyMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server