This server provides AI agents with an MCP interface to RunAPI's Midjourney services, supporting:
Image generation: Create images from text with text_to_image.
Image editing: Edit images using edit_image, optionally with masking.
Video generation: Convert images to video (image_to_video) and extend existing videos (extend_video).
Prompt tools: Get seed (get_seed), generate prompts from images (image_to_prompt), and shorten prompts (shorten_prompt) — all synchronous.
Task management: Create async tasks with optional waiting; poll status/results via get_task.
Pricing: Check current pricing for models/endpoints with check_pricing, no auth required.
Authentication: Log in via browser PKCE flow or provide an API key in environment/config.
Integration: Works with Claude Code, Cursor, VS Code, and any MCP-compatible host.
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., "@RunAPI Midjourney MCP Server Generate a Midjourney image of a futuristic city at night."
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.
@runapi.ai/midjourney-mcp is a focused Model Context Protocol server for the Midjourney model line on RunAPI.
It gives MCP-compatible assistants direct access to 7 endpoints and 3 model variants without loading the full RunAPI catalog.
Use this per-model server when an agent should stay scoped to Midjourney. Use @runapi.ai/mcp when one assistant should discover every RunAPI model line.
Related MCP server: MidjourneyMCP
Add it to Claude Code:
claude mcp add midjourney -s user -- npx -y @runapi.ai/midjourney-mcpUse project scope when the server should be shared with a repository:
claude mcp add midjourney -s project -- npx -y @runapi.ai/midjourney-mcpCodex, Cursor, Windsurf, VS Code, Roo Code, and other MCP hosts can use the same stdio command:
{
"mcpServers": {
"midjourney": {
"command": "npx",
"args": ["-y", "@runapi.ai/midjourney-mcp"]
}
}
}check_pricing works before sign-in. For task creation and status polling, ask your assistant to call the login tool. It opens a browser login and saves credentials to ~/.config/runapi/config.json, the same file used by runapi login.
Headless and CI hosts can still set RUNAPI_API_KEY before starting the MCP host.
Ready-made examples are in examples/ for Claude, Cursor, Windsurf, VS Code, and Roo Code.
Tool | Auth | Purpose |
| Yes | Create a Midjourney edit image task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Create a Midjourney extend video task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Run a Midjourney get seed operation synchronously. Returns the operation result. |
| Yes | Run a Midjourney image to prompt operation synchronously. Returns the operation result. |
| Yes | Create a Midjourney image to video task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Run a Midjourney shorten prompt operation synchronously. Returns the operation result. |
| Yes | Create a Midjourney text to image task and optionally wait for a terminal status. Returns the task id, status, and output URLs. |
| Yes | Fetch the current status and latest payload for an existing task. |
| No | Look up current pricing for a Midjourney model and endpoint. |
Midjourney covers 3 model variants across 7 endpoints. Each tool accepts the models listed for it:
Tool | Models |
|
|
|
|
| no model parameter |
| no model parameter |
|
|
| no model parameter |
|
|
Model availability can change between releases. Use check_pricing or the Midjourney model page for the current catalog view.
Ask your assistant in natural language; it can inspect pricing, create the task, and return the task id plus output URLs.
Run a Midjourney edit image task with RunAPI.The assistant can call check_pricing, then edit_image, and return the task id, status, and output URLs.
Create the task but don't wait for it to finish.The assistant calls the create tool with wait: false and returns the task id. Check on it later with get_task.
Check current Midjourney pricing, then create the task if it matches my request.The assistant calls check_pricing and can link to the Midjourney model page for the canonical catalog entry.
The server resolves auth in this order:
RUNAPI_API_KEY environment variable, useful for headless and CI hosts
~/.config/runapi/config.json, created by the MCP login tool or runapi login
No key, which still allows check_pricing
The config file is normally managed by login. A pre-provisioned headless config can use:
{
"apiKey": "your_runapi_key"
}Do not commit real API keys.
Resource | URL |
Midjourney model page | |
npm package | |
GitHub repository | |
RunAPI MCP overview | |
RunAPI docs |
Licensed under the Apache License, Version 2.0.
Look up RunAPI pricing for the midjourney model line.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model slug. Defaults to the line's primary model. | |
| action | No | Endpoint name. Defaults to the endpoint that offers the model. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It only says 'look up pricing,' implying a read-only operation, but does not explicitly state no side effects, authentication needs, or rate limits. For a tool that queries pricing, more transparency (e.g., 'this tool does not modify any data') would be beneficial.
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 extraneous information. It directly states the tool's function without any filler, achieving maximum 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 no output schema and low tool complexity (2 optional enum parameters), the description is too sparse. It does not explain what the pricing lookup returns (e.g., cost per unit, subscription info), nor does it mention default behavior for unspecified parameters. Sibling tools are action-oriented, but for a pricing tool, more context about the output format or usage scenarios 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 coverage is 100%, and the description mentions 'midjourney model line' which aligns with the model parameter's enum values, but it does not add any meaning beyond the schema. The schema already documents model and action with descriptions and defaults. Baseline 3 is appropriate since description adds no extra 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?
Description clearly states the tool's purpose: 'Look up RunAPI pricing for the midjourney model line.' This is a specific verb ('look up') and resource ('pricing'), and it scopes to the midjourney model line, distinguishing it from sibling tools that perform actions like image generation or editing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for pricing lookups, but does not state when not to use it or suggest other tools for similar purposes. Sibling tools are all action-oriented, so the usage is somewhat implied, but lack of explicit guidelines keeps it at a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Midjourney task on RunAPI (edit image). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| prompt | Yes | ||
| mask_url | No | ||
| timeout_ms | No | ||
| callback_url | No | ||
| poll_interval_ms | No | ||
| source_image_url | Yes | ||
| include_split_images | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions task creation and return fields, omitting behavioral details like polling behavior (though wait parameter exists), destructive nature, or authentication requirements.
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, concise but too terse. It front-loads the primary action but omits crucial details for a 9-parameter tool.
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 9 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain required parameters, how they work together, or the response format beyond a vague reference.
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 only 22% (2 of 9 params have descriptions). The tool description adds no additional parameter meaning or examples, leaving most parameters unexplained.
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 it creates a Midjourney task for editing images, returns task id, status, and output URLs. This distinguishes it from sibling tools like text_to_image or image_to_video.
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 vs alternatives. The description does not specify scenarios or compare with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Midjourney task on RunAPI (extend video). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| prompt | No | ||
| timeout_ms | No | ||
| callback_url | No | ||
| source_task_id | Yes | ||
| poll_interval_ms | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only mentions return values (task id, status, output URLs) but does not disclose side effects, authentication needs, rate limits, or async 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?
Description is a single short sentence, concise and front-loaded, but may be too brief to convey necessary information.
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 7 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the concept of 'extend video' or input parameter roles beyond basic return values.
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 low (29%). Description adds no explanation for parameters like 'source_task_id', 'prompt', 'timeout_ms', etc., 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 states 'Create a Midjourney task on RunAPI (extend video)', specifying a verb ('Create'), resource ('Midjourney task'), and context ('extend video'). It distinguishes from siblings like 'image_to_video' which imply different video operations.
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 alternatives such as 'image_to_video' or 'edit_image'. The description lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a synchronous Midjourney operation on RunAPI (get seed). Returns the operation result.
| Name | Required | Description | Default |
|---|---|---|---|
| image_id | Yes |
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 mentions the operation is synchronous and returns a result, but does not explain side effects, permissions, or what the result contains. This is minimal transparency for a tool that performs a specific operation.
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 and has no waste, but it is under-specified. The phrase 'Run a synchronous Midjourney operation on RunAPI' is generic filler, and the key information is only the parenthetical '(get seed)'. It is concise but not clearly front-loaded with actionable specifics.
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 simplicity (one parameter, no output schema, no annotations), the description still leaves critical gaps. It does not clarify what the operation does with the image_id, what the result structure looks like, or any constraints. The sibling tools context suggests a suite of operations, but this description does not position get_seed within that workflow.
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 only parameter, image_id, has no description in the schema and the tool description does not explain its meaning or format. With 0% schema coverage and no compensation in the description, the parameter is effectively undocumented beyond its name.
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 runs a synchronous Midjourney operation to get seed, which identifies the action somewhat, but does not clearly define what 'seed' is in this context. It distinguishes from siblings only through the parenthetical '(get seed)', which is just the tool name reused, making it partially tautological.
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 get_task or other image operations. The description does not mention when this should be invoked or any prerequisites, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current status and latest result payload for a midjourney task.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Asynchronous endpoint the task was created on. | |
| task_id | Yes | Task id returned when the task was created. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully describe behavior. It states the tool fetches status and payload, implying a read operation, but lacks details about traits like idempotency, authentication needs, or rate limits. The description is minimally transparent.
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 unnecessary words. It is front-loaded and efficiently conveys the tool's core purpose.
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?
While the tool's purpose is clear, there is no output schema, and the description only vaguely mentions 'latest result payload' without detailing the return structure. For a fetch tool, users would benefit from knowing the format of the result, which is missing.
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 meaning beyond what the schema already provides; it merely reiterates the function without explaining parameter usage or 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 uses a specific verb ('Fetch') and identifies the resource ('current status and latest result payload for a midjourney task'). It clearly distinguishes this tool from siblings like edit_image or text_to_image, which are for creation or modification rather than retrieval.
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 exclusions or context for sibling tools are mentioned, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a synchronous Midjourney operation on RunAPI (image to prompt). Returns the operation result.
| Name | Required | Description | Default |
|---|---|---|---|
| source_image_url | Yes |
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 that the operation is 'synchronous' and 'returns the operation result', offering some behavioral insight. However, it does not disclose side effects, authentication requirements, rate limits, or failure behavior, which is a significant gap for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no redundant or filler content. It front-loads the essential purpose and adds the synchronous and return-value details without waste. Every word earns its place.
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 annotations and output schema, the description is incomplete. It does not specify what the operation result contains (likely a prompt string), nor does it address error conditions or how the result is structured. With one parameter and no output schema, more explanation is needed to fully prepare an agent.
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 has one parameter, source_image_url, with no description (0% coverage). The description does not mention this parameter or explain what constitutes a valid input (e.g., URL format, accessibility). Since schema coverage is zero, the description must compensate, but it does not, leaving the parameter semantically empty.
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 'Run a synchronous Midjourney operation on RunAPI (image to prompt)', which clearly identifies the tool's purpose as converting an image to a prompt. The parenthetical 'image to prompt' differentiates it from sibling tools like image_to_video and text_to_image. However, the verb 'Run' is generic rather than a specific action like 'convert' or 'generate', so it falls short of a 5.
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. It does not mention use cases, prerequisites, or exclusions. There is no reference to sibling tools such as image_to_video or shorten_prompt, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Midjourney task on RunAPI (image to video). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| prompt | No | ||
| timeout_ms | No | ||
| enable_loop | No | ||
| callback_url | No | ||
| poll_interval_ms | No | ||
| source_image_url | Yes | ||
| output_resolution | No | ||
| last_frame_image_url | No |
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 mentions returns (task id, status, output URLs) but fails to describe polling behavior, destructive nature, or side effects. The 'wait' param suggests polling, but this is not explained in the description.
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?
Very concise single sentence with no wasted words. However, it could benefit from a bit more structure, e.g., separating input and output details. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, 10 parameters (1 required), but description lacks context on common use cases, parameter interactions (e.g., 'wait' vs 'callback_url'), or success criteria. The tool is more complex than the description suggests.
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 only 20% (2/10 parameters have descriptions). The description does not clarify any parameters beyond return format, leaving the agent to infer from schema names and types. For a tool with many optional parameters, this is insufficient.
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 it creates a Midjourney task for image-to-video conversion, with specific verb 'Create' and resource 'Midjourney task on RunAPI'. It distinguishes from sibling tools like 'extend_video' and 'text_to_image' by focusing on image input.
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 vs alternatives (e.g., using 'extend_video' for extending videos). No prerequisites, context, or exclusions provided, leaving the agent without decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Authenticate RunAPI by opening a browser PKCE login flow and saving the API key to ~/.config/runapi/config.json.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Re-run browser login when the current credential comes from the local config file. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the browser login flow and config file saving, but does not mention side effects like overwriting existing credentials, required user interaction, or behavior on failure. No annotations exist to compensate.
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 that is front-loaded with the core purpose and mechanism. No redundant information; every word adds value.
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 simple parameter (optional boolean) and no output schema, the description adequately covers what the tool does. Could mention subsequent API key usage, but completeness is high for a login tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about the overall flow but does not elaborate on the 'force' parameter beyond the schema's own description.
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 'Authenticate', the resource 'RunAPI', and the mechanism 'PKCE login flow'. It distinguishes from siblings (all unrelated to auth) and specifies the output location.
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. Sibling tools are unrelated to authentication, implying it's the primary auth tool, but no 'when-not' or 'if already authenticated' advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a synchronous Midjourney operation on RunAPI (shorten prompt). Returns the operation result.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the operation is synchronous and returns an operation result, which is useful, but it does not explain potential side effects, authentication needs, or what the result actually contains. This is insufficient for a tool with zero structured behavioral hints.
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 of about 15 words. It front-loads the operation type and outcome without redundancy. Every word contributes meaning, and it avoids unnecessary padding.
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 only one parameter, no output schema, and no annotations, the description is too thin. It does not explain what the operation result looks like, any prerequisites, or how it integrates with Midjourney. The tool is left under-specified for an agent to invoke confidently without further investigation.
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 has one parameter 'prompt' with no description, and schema coverage is 0%. The description only indirectly refers to the prompt via the tool name and the parenthetical. It does not explicitly state that 'prompt' is the text to shorten, nor does it provide format constraints or examples. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as running a synchronous Midjourney operation to shorten a prompt. The parenthetical '(shorten prompt)' disambiguates it from sibling tools like image_to_prompt or text_to_image. However, the phrase 'Run a synchronous Midjourney operation' is slightly generic, so it doesn't earn a 5.
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. The description only states what it does, not when it should be invoked or which sibling tools are not appropriate. There is no mention of exclusions or preferred scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Midjourney task on RunAPI (text to image). Returns a task id, status, and output URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Poll until the task reaches a terminal status. | |
| model | No | RunAPI model slug for this model line. | |
| prompt | Yes | ||
| timeout_ms | No | ||
| callback_url | No | ||
| poll_interval_ms | No | ||
| include_split_images | No | ||
| enable_prompt_translation | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions return values (task id, status, output URLs) but does not disclose that the task may be asynchronous, that it polls by default, or any other behavioral implications. Without annotations, more context is needed.
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 wasted words. It is front-loaded with the key action and result.
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 8 parameters and no output schema or annotations, the description is insufficient. It omits details about task lifecycle, parameter effects, and edge cases.
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?
With only 25% schema description coverage, the description adds no explanation beyond the schema for most parameters. It does not clarify parameters like include_split_images or enable_prompt_translation.
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 'Create a Midjourney task on RunAPI (text to image)', which specifies the verb, resource, and domain. It distinguishes from sibling tools like edit_image or image_to_video.
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 provided on when to use this tool vs alternatives such as edit_image or image_to_video. The description simply states the function without context or exclusions.
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. Dates show when Glama detected each change.
v0.3.0check_pricingedit_imageextend_videoget_seedget_taskimage_to_promptimage_to_videologinshorten_prompttext_to_imageEach tool targets a distinct action or resource: login is for authentication, the four creation tools (text_to_image, image_to_video, extend_video, edit_image) are clearly different task types, the three synchronous operations (get_seed, image_to_prompt, shorten_prompt) are distinct utilities, and get_task/check_pricing serve separate purposes. No two tools appear interchangeable.
Tool names mostly follow a verb_noun pattern (edit_image, extend_video, get_seed, shorten_prompt, get_task, check_pricing), but the creation tools (text_to_image, image_to_video) use a noun_to_noun pattern that describes the operation rather than a verb. This is a minor inconsistency but overall the naming style is predictable and readable.
With 10 tools, the server is well-scoped for a Midjourney API wrapper. Each tool serves a clear function, and the count is within the ideal 3-15 range. The set is neither bloated nor thin.
The server covers the core Midjourney workflows: login, all major generation types (text-to-image, image-to-video, extend video, edit image), task status retrieval, and several common utilities (seed, prompt inversion, prompt shortening). Minor gaps exist such as upscale or variation operations, but the essential lifecycle is present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create images & video from any MCP agent — 17 models, spend limits, one URL.
MCP server for Midjourney AI image generation and editing
OCR, transcription, file extraction, and image generation for AI agents via MCP.
Focused MCP server for OpenAI image/audio generation (v2.0.0). Wraps endpoints via HAPI CLI.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/runapi-ai/midjourney-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
