RunAPI Midjourney MCP Server

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3/5 across 10 of 10 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
Add a glama.json file to provide metadata about your server.
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?
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose3/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness3/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/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 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

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:

[![midjourney-mcp MCP server](https://glama.ai/mcp/servers/runapi-ai/midjourney-mcp/badges/card.svg)](https://glama.ai/mcp/servers/runapi-ai/midjourney-mcp)

Score Badge

Copy to your README.md:

[![midjourney-mcp MCP server](https://glama.ai/mcp/servers/runapi-ai/midjourney-mcp/badges/score.svg)](https://glama.ai/mcp/servers/runapi-ai/midjourney-mcp)

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/runapi-ai/midjourney-mcp'

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