grok-imagine-mcp

Server Quality Checklist

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

Latest release: v0.1.11
Disambiguation5/5
Each tool targets a distinct operation: authentication, specific generation types, task status, and pricing. No two tools overlap in purpose, so an agent can easily select the correct one.
Naming Consistency4/5
Most tools follow a verb_noun pattern (edit_image, upscale_image, get_task), but three tools (image_to_video, text_to_image, text_to_video) use a transformation-style name without a leading verb. The naming is not chaotic but the pattern is not fully uniform.
Tool Count5/5
With 9 tools, the server covers authentication, all core generation capabilities, task retrieval, and pricing—nothing feels superfluous. This is a well-scoped set for an image/video generation service.
Completeness4/5
The tool surface includes creation for all media types, status retrieval, login, and pricing. Missing a cancel/delete task operation and possibly a list-tasks endpoint, but the core workflow of submit-and-retrieve is fully supported.
Average 3.4/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 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, the description carries the full burden of disclosure. It mentions task creation and return values, but omits key behavior like asynchronous execution, polling/wait semantics, safety checker enablement, potential costs, or permission requirements. This is a notable gap for a task-creating tool.
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 a single, front-loaded sentence that states the action and outcome with no filler. It is efficient and easy to parse, though it could benefit from a bit more detail on usage context.
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?
For an 8-parameter async task tool with no output schema and no annotations, the description is thin. It does not explain how to retrieve the final result (e.g., via get_task or polling), the role of callback_url, or the significance of wait, leaving the agent without enough context to invoke it effectively in complex workflows.
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 75%, so the schema documents most parameters. The description adds no parameter-specific meaning, but the uncovered parameters (timeout_ms, poll_interval_ms) are self-explanatory. Given the high coverage, a baseline of 3 is appropriate; the description does not hinder understanding.
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 creates a Grok Imagine task for image editing, which distinguishes it from sibling tools like text_to_image or upscale_image. It also notes the return type (task id, status, output URLs), adding clarity beyond just the name.
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 explicit guidance on when to use this tool versus alternatives. The description implies it's for editing existing images but does not mention exclusions, prerequisites, or preferred scenarios, leaving the agent to infer from the name and sibling context.
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 provided, the description carries the full burden of behavioral disclosure. It only states that the tool returns a task id, status, and output URLs, implying an asynchronous task-based flow but without details on polling, error handling, safety checks, or mutability. The description fails to disclose potential side effects or invocation implications of this create operation.
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 concise sentence that front-loads the primary purpose and briefly mentions return values. There is no wasted text, and the structure is efficient and easy to parse.
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?
The tool has 15 parameters, no output schema, and no annotations, yet the description is extremely brief. It does not explain how to initiate the task (e.g., which input source to provide), the asynchronous behavior, timeout/polling mechanics, or how to interpret the returned task id and status. This is inadequate for a tool of this complexity.
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 high (87%), so the schema already provides substantial parameter meaning. The description itself adds no parameter-specific details beyond the phrase 'image to video', which is already implied by the tool name. As a result, the description does not compensate for the few remaining undocumented parameters, but the schema's high coverage makes this a neutral baseline.
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 creates a Grok Imagine task for image-to-video conversion on RunAPI. The verb 'Create' plus the resource 'Grok Imagine task' and the mode '(image to video)' provide specific scope. This sufficiently distinguishes it from sibling tools like text_to_video and 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 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 such as text_to_video or extend_video. It also does not mention any prerequisites like needing a source_task_id or source_image_url, which are critical for invocation. The absence of usage context leaves the agent unclear about appropriate scenarios.
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 must carry the full burden. It discloses the async task model by mentioning the return of 'a task id, status, and output URLs,' which implies a non-blocking workflow. However, it does not mention prerequisites (e.g., source_task_id from a completed task), auth requirements, or potential side effects, leaving notable gaps.
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, front-loaded sentence with no filler. It efficiently states the action, the platform, and the return values. Every word earns its place, making it highly concise and well-structured.
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 5 parameters, no output schema, and no annotations, this description is too sparse. It does not explain the task-based async workflow, the role of wait/timeout/callback, or the relationship between the source task and the upscaler. The return values are mentioned, but terminal statuses are not, leaving the agent under-informed for a tool of this complexity.
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 60% (wait, callback_url, source_task_id have descriptions), so the baseline is 3. The description adds no parameter-specific detail; it relies entirely on the schema. It does not clarify how source_task_id relates to the upscaling operation, but the schema already documents it.
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 a clear action: 'Create a Grok Imagine task on RunAPI' with the parenthetical '(upscale image)' clarifying the specific purpose. This distinguishes it from siblings like edit_image or text_to_image, though the phrase 'Grok Imagine task' introduces slight ambiguity.
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 given on when to use this tool versus alternatives. Sibling tools such as edit_image or image_to_video exist, but the description never mentions them or provides exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context by stating 'Returns a task id, status, and output URLs', giving a clue about async task behavior. However, with no annotations, it does not disclose async semantics, polling details, side effects, or required permissions. This is modest but incomplete transparency.
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 fluff, front-loaded with the action verb 'Create'. Every word adds value, balancing purpose and return information efficiently.
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?
The tool has 9 parameters, no output schema, and no annotations, making it moderately complex. The description only covers the basic purpose and rough return shape, but fails to explain when to use wait vs callback_url, how to integrate with get_task, what terminal statuses look like, or any prerequisites. This is insufficient for confident invocation.
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 78% (7 of 9 params have descriptions), just below the 80% high threshold. The description adds no parameter semantics; notably, timeout_ms and poll_interval_ms are undocumented in both schema and description, leaving important behavioral knobs unexplained. The description fails to compensate for this gap.
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 'Create a Grok Imagine task on RunAPI (text to image)' with a specific verb and resource, and the parenthetical clarifies the exact operation. This distinguishes it from sibling tools like edit_image, upscale_image, and text_to_video. It also mentions the return format, reinforcing purpose.
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 when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives, exclusions, or context like 'Use this to generate images from text prompts'. An agent would have to infer usage solely from the tool name and the generic description, which is not explicit.
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 only states it creates a task and returns ids/status/URLs, but does not disclose important behavior such as it being asynchronous, the ability to poll (wait, poll_interval_ms), or webhook support. This is a significant gap for a task-creation 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 is a single concise sentence that front-loads the purpose and includes return value info. Every word earns its place, with no unnecessary fluff or repetition.
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?
The tool has 8 parameters, no output schema, and no annotations. The description explains the core purpose and return values, but lacks crucial context about async behavior, how to retrieve results (get_task), and the effect of the wait flag. This is incomplete for a complex task-creation 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 75%, with most parameters already having clear descriptions. The description adds no additional parameter semantics beyond the context of 'extend video'. Since coverage is moderate and not low, a baseline of 3 is appropriate; the schema handles parameter documentation.
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 Grok Imagine task on RunAPI (extend video)', which is a specific verb+resource+scope. It distinguishes from siblings like text_to_video and image_to_video by explicitly saying 'extend video'. Also mentions it returns task id, status, and output URLs.
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 implies usage for extending an existing video via 'extend video', but it does not explicitly state when to use this tool vs alternatives or provide exclusions. There is no mention of prerequisites like needing a completed prior task, which is only in the schema. Thus, usage guidance is implied, not explicit.
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 disclosing behavior. It mentions that the tool returns a task id, status, and output URLs, but omits critical aspects like the async task lifecycle, polling behavior, and the need to call get_task when wait=false. It also does not disclose potential side effects or the fact that reference_image_urls is ignored.
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 only two sentences, front-loaded with the main verb and purpose, and contains no filler words. 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?
For a 12-parameter async task tool with no annotations or output schema, the description is too sparse. It lacks essential context about the task lifecycle, the role of callback_url, and the meaning of safety checker settings, leaving the agent to rely heavily on 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?
Schema description coverage is 83%, which is high, so the baseline is 3. The description adds no parameter-level details, but the mention of returning task id and output URLs loosely relates to the wait parameter.
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 creates a Grok Imagine text-to-video task, using a specific verb and resource. The phrase 'text to video' distinguishes it from sibling tools like text_to_image and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies the tool's purpose as text-to-video generation, which provides clear context for when to use it. However, it does not mention exclusions or directly contrast it with alternative tools, though sibling names make the differentiation obvious.
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 provided, the description carries the full burden. It says 'look up,' which implies a read-only operation, but it does not disclose additional behavioral traits such as authentication requirements, rate limits, or response format. For a simple pricing lookup, this is adequate but not rich.
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, front-loaded sentence with no wasted words. It clearly states the purpose without unnecessary elaboration.
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?
The schema covers parameters and defaults, but the description does not explain what the tool returns or how to combine model/action for pricing lookup. Since there is no output schema, the description could be more informative about the response, but the tool is simple and the scope is minimal.
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 input schema provides 100% description coverage for both parameters, including defaults. The description adds no extra meaning beyond what the schema already states. Baseline 3 applies because the schema does the heavy lifting.
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: 'Look up RunAPI pricing' with a specific scope ('grok-imagine model line'). This uses a specific verb and resource, distinguishing it from sibling tools like edit_image or get_task, which are operational or task-related.
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 implies usage: when pricing for the grok-imagine model line is needed, use this tool. However, it does not explicitly state when not to use it or mention alternative tools if the user needs something else (e.g., actual image generation). It lacks clear exclusions or alternative 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?
The word 'Fetch' implies a read-only operation, and 'current status' suggests it may return incomplete or in-progress states. However, with no annotations, the description does not disclose error behavior, whether it modifies anything, or any authentication needs. It is minimally transparent but not misleading.
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?
A single, front-loaded sentence with no redundant wording. Every word adds value, clearly stating the action and the resource.
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?
The tool is relatively simple with two parameters and no output schema. The description covers the main purpose and even mentions 'latest result payload,' but it does not explain possible status values, polling behavior, or error conditions, leaving some ambiguity for the agent.
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?
Both parameters are fully described in the input schema with 100% coverage. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
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 the specific verb 'Fetch' with the resource 'current status and latest result payload for a grok-imagine task.' This clearly distinguishes it from sibling tools that create or edit tasks, making its purpose immediately obvious.
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?
Usage is implied through the name and description; it is for retrieving task status, but there is no explicit guidance on when to use it, how to poll, or which alternatives to avoid. No exclusions or alternatives are mentioned.
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 full burden. It discloses the interactive browser flow, PKCE method, and the side effect of saving the API key to a specific file path. This provides good transparency for a login 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 is a single sentence that front-loads the key action ('Authenticate RunAPI') and efficiently conveys the method and output. No wasted words.
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?
For a login tool with one boolean parameter and no output schema, the description covers the core purpose and side effect (file write). Minor gaps remain, such as behavior when already authenticated or if browser is unavailable, but overall complete.
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% for the lone 'force' parameter, and the tool description does not add extra meaning beyond what the schema already provides. 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 'authenticate', the resource 'RunAPI', and the specific action: opening a browser PKCE login flow and saving the API key. This distinguishes it from sibling tools which are unrelated (image/video generation and pricing).
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 implies this is the initial authentication tool but does not explicitly state when to use it versus alternatives (e.g., if another authentication method exists). No guidance on when to use the 'force' parameter beyond its schema description.
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:

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

Score Badge

Copy to your README.md:

[![grok-imagine-mcp MCP server](https://glama.ai/mcp/servers/runapi-ai/grok-imagine-mcp/badges/score.svg)](https://glama.ai/mcp/servers/runapi-ai/grok-imagine-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/grok-imagine-mcp'

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