Skip to main content
Glama
runapi-ai

grok-imagine-mcp

by runapi-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

upscale_image

Upscale an image from a completed Grok Imagine task by providing its task ID, and receive a new task ID, status, and output URLs.

Instructions

Create a Grok Imagine task on RunAPI (upscale image). Returns a task id, status, and output URLs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoPoll until the task reaches a terminal status.
timeout_msNo
callback_urlNoWebhook URL for terminal Task delivery.
source_task_idYesCompleted prior Grok Imagine video Task ID.
poll_interval_msNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.13
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / poll_interval_ms / maximum
      Added value: +9007199254740991
    • addedInput schema / properties / timeout_ms / maximum
      Added value: +9007199254740991
  2. Changed3 schema fields changedv0.1.11
    • addedInput schema / properties / callback_url
      Added value: +{
+  "description": "Webhook URL for terminal Task delivery.",
+  "type": "string"
+}
    • addedInput schema / properties / source_task_id
      Added value: +{
+  "description": "Completed prior Grok Imagine video Task ID.",
+  "type": "string"
+}
    • addedInput schema / required
      Added value: +[
+  "source_task_id"
+]
  3. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior. It states that it returns a task id and status, indicating an asynchronous operation, and mentions output URLs. However, it does not mention authentication requirements, potential costs (despite check_pricing sibling), or any side effects beyond task creation. This is partial transparency; it covers the core flow but misses operational details.

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, compact sentence that front-loads the action and result. Every word serves a purpose: it identifies the tool's function, the platform, and the returns. There is no redundancy or fluff, making it highly efficient for an agent to parse quickly.

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 no output schema and no annotations, so the description must carry full contextual weight. It mentions returning a task id and output URLs, but does not explain how to poll or retrieve final results (e.g., via get_task), nor does it clarify the role of the wait parameter or callback_url. This is a significant gap for a tool that creates asynchronous tasks.

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 60%, with two parameters (timeout_ms and poll_interval_ms) lacking descriptions. The tool description adds no parameter-specific information beyond what is in the schema. It does not explain the meaning or interaction of parameters like wait or callback_url, leaving gaps that the schema also does not fully address.

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 a specific action (create a Grok Imagine task) and its purpose (upscale image), which distinguishes it from siblings like text_to_image or text_to_video. The return value mention (task id, status, output URLs) adds clarity. It could be more explicit about the upscaling context, but the core purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for upscaling an image, which is enough for an agent to infer when to use it. However, it does not explicitly mention when not to use it or provide alternatives (e.g., use edit_image for other edits). No comparison with siblings is offered, so the agent must rely on the name and description to select it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools