grok-imagine-mcp

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

With no annotations, the description carries the full behavioral burden. 'Look up' implies a read-only, side-effect-free operation, which is useful context, but details such as authentication requirements, rate limits, or return behavior are absent.

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?

A single, front-loaded sentence with zero waste. It conveys the complete purpose without unnecessary qualifiers.

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?

For a simple read-only lookup with fully documented schema parameters and no output schema, the description is largely sufficient: an agent knows what it does and how to invoke it. It misses explicit usage guidance and any indication of the return format, which are minor gaps for this complexity level.

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 both parameters are fully documented in the schema. The description adds the model line context ('grok-imagine'), which slightly sharpens the default for the model parameter, but it does not explain the action enum 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 a specific verb ('Look up'), resource ('RunAPI pricing'), and scope ('grok-imagine model line'). It is immediately distinguishable from sibling action endpoints and login/get_task.

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 gives no explicit when-to-use or when-not-to-use guidance, nor does it name any alternative. It merely restates the tool's purpose, leaving the agent to infer that it is called whenever pricing is needed.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does usefully disclose the async task model and the return shape (task id, status, output URLs), but omits auth requirements, that wait defaults to true and triggers polling, and that some declared parameters are rejected by this model.

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?

Two short sentences, front-loaded with the action and resource, and no filler. Slightly jargon-heavy ('Grok Imagine task on RunAPI') but efficient overall.

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?

For a 12-parameter, zero-required, no-output-schema tool with no annotations, the description covers purpose and return values but leaves polling behavior, the default wait=true, and rejected-parameter caveats unexplained. Adequate but with clear gaps.

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 83%, above the 80% threshold, so the schema already documents most parameters. The description adds no parameter-level detail such as prompt format, aspect ratio values, or callback semantics, so the baseline 3 applies.

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 a specific verb and resource: creating a Grok Imagine task for image editing on RunAPI. 'edit image' distinguishes it reasonably from siblings like text_to_image and upscale_image, though it never explicitly contrasts itself with them.

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 when-to-use guidance, no mention of alternatives (e.g., upscale_image, text_to_image), and no prerequisites such as needing a source image URL. The agent must infer all routing decisions 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.

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

With no annotations, the description carries the full burden, and it does disclose the asynchronous task model and the return shape (task id, status, output URLs). However, it omits that this is a mutating, credit-consuming operation, how polling/wait behaves, and what happens on timeout or failure despite the schema exposing wait, timeout_ms, poll_interval_ms, and callback_url.

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?

A single front-loaded sentence with no filler; every clause earns its place. It is arguably too terse for an 8-parameter mutation tool, but there is no wasted text.

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?

For an 8-parameter, mutation-style task tool with no output schema and no annotations, the description is far too thin. It should cover the source-task dependency, duration constraints, and the async/polling contract that the schema hints at.

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 75%, so most parameters are partially documented in the schema, but the description adds no meaning at all beyond 'extend video' — nothing about start_seconds positioning, the allowed extension durations, or how source_task_id is consumed.

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 gives a specific verb and resource ('Create a Grok Imagine task ... extend video') and names the platform, which the bare name extend_video would not convey. It is clear what the tool produces, though it does not explicitly distinguish itself from video-producing siblings such as image_to_video or text_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?

There is no when-to-use guidance, no exclusions, and no mention of alternatives. The fact that it operates on a prior completed task is only inferable from the required source_task_id in the schema, not from the description.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return content (status and latest result payload), which is useful, but says nothing about pending/failed task states, polling cadence, auth, or rate limits.

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?

A single, front-loaded sentence with no filler; the resource and returned fields are stated immediately.

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?

For a simple two-parameter read tool with a fully documented schema and no output schema, the description covers the essentials. It falls short on lifecycle context (polling behavior, terminal states) that an agent needs to use it correctly in the async 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?

Schema description coverage is 100% – both task_id and the action enum are documented in the schema. The description adds no additional parameter meaning (e.g. that action must match the endpoint the task was created on), so baseline 3 applies.

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?

States a specific verb (fetch) and resource (current status + latest result payload for a task), which clearly separates it from the sibling creation endpoints like text_to_image or extend_video. It does not explicitly name a sibling, but the resource is unambiguous.

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 when-to-use guidance, no mention that this is the polling companion to the async creation tools, and no prerequisites or exclusions. The polling intent is only loosely implied by 'current status'.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it does at least characterize the async task model by stating the call returns a task id, status, and output URLs. It stops there – no mention of cost, failure behavior, or auth requirements, and the async/polling nature is only hinted at rather than explained.

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?

Two tight sentences with no filler, and the core action is front-loaded ahead of the return-value note. It is appropriately sized, though the terseness contributes to the coverage gaps noted elsewhere.

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?

For a 15-parameter generation tool with no annotations and no output schema, the description is thin: it briefly covers the return payload, which is genuinely useful without an output schema, but says nothing about the async lifecycle or how wait/timeout/callback interact. Adequate as a minimum but with clear gaps.

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 high at 87%, so the schema already documents most parameters, and the description adds no syntax, format, or interplay details beyond it. Baseline of 3 is appropriate when the schema does the heavy lifting and the prose adds nothing on top.

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?

States a specific verb and resource ('Create a Grok Imagine task ... image to video') and names the underlying provider, so the agent knows it is an image-to-video generation call. It does not explicitly contrast with siblings like text_to_video or extend_video, but the '(image to video)' qualifier is enough to separate it from those without opening a schema.

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 gives no when-to-use guidance and never names an alternative, even though siblings text_to_video and extend_video are obvious confusables. It also omits the prerequisite that a source image (URL or prior task id) must be supplied despite zero required parameters, leaving the agent to infer the workflow entirely from the schema.

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

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

With no annotations, the description carries the behavioral burden. It discloses the interactive browser flow and the file write side effect (config.json). However, it does not mention that it may overwrite existing credentials or that it could block waiting for user input, though these are implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the action ('Authenticate RunAPI') and provides necessary details without extraneous 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?

For a simple login tool with one optional parameter and no output schema, the description covers the core purpose and side effect. It lacks an explicit statement that this is a prerequisite for other tools, but that is implied.

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% (the only parameter 'force' has a description). The tool description adds no additional meaning about parameters beyond the schema, so the baseline of 3 applies.

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 tool's purpose with a specific verb ('Authenticate'), target resource ('RunAPI'), method ('browser PKCE login flow'), and side effect (saving to config.json). It is distinct from sibling tools, none of which relate to authentication.

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 implies usage (to authenticate RunAPI) but does not explicitly say when to run it (e.g., before other RunAPI tools) or when to use the 'force' parameter. Since there are no alternative auth tools among siblings, 'vs alternatives' is not applicable.

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

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

With no annotations, the description carries the full burden, and it does disclose the return shape (task id, status, output URLs) and implies async task creation. It omits other important traits: whether this is a paid/consuming operation, auth requirements, and the polling behavior implied by the wait/poll_interval_ms parameters.

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?

Two compact sentences, front-loaded with the action and followed by the return contract. Nothing is padded, though the parenthetical '(segment map)' is low-value restatement.

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?

For a 7-parameter task-creation tool with no annotations and no output schema, stating the return values is genuinely useful. But the description leaves the tool's actual semantics ('segment map'), usage context, and the async/polling lifecycle unaddressed, so an agent still needs the sibling get_task to close the loop by inference.

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 71%, leaving timeout_ms and poll_interval_ms with no documented meaning in either place. The description adds no parameter guidance at all, so it fails to compensate for the coverage gap on a 7-parameter tool.

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?

States a specific verb and resource ('Create a Grok Imagine task on RunAPI') and names the operation type ('segment map'). However, '(segment map)' merely restates the tool name, and nothing distinguishes this from siblings like edit_image, text_to_image, or image_to_video that also create Grok Imagine tasks. The agent can tell it creates a task but not what a 'segment map' produces.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling task-creation tools. The only hint of routing ('use image_url instead') lives in the source_task_id parameter description, not the tool description.

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

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

With no annotations, the description carries the full burden, and it does disclose the async task model plus the return shape (task id, status, output URLs). However, it omits the wait/polling behavior that governs the call's blocking semantics, any auth or rate-limit context, and what a terminal status failure looks like.

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?

Two sentences with no filler, and the operation is front-loaded ahead of the return-value note. Efficient, though the second sentence duplicates value already implied by the tool's nature.

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?

There is no output schema, and the description partially fills that gap by naming the returned fields. But for a 9-parameter, annotation-free creation tool, the absence of usage, polling, and parameter detail leaves meaningful gaps.

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 78% with 9 parameters, and two parameters (timeout_ms, poll_interval_ms) have no schema description at all. The description adds zero parameter meaning beyond what the schema already provides, so it does not compensate for the coverage gap.

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?

States a specific verb and resource ('Create a Grok Imagine task on RunAPI') and disambiguates the modality with '(text to image)', which separates it from edit_image and image_to_video. It does not explicitly name a sibling, so it stops 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?

There is no guidance on when to choose this over edit_image, text_to_video, or upscale_image, and no prerequisites are stated. The only usage hint is the parenthetical modality label, which is implied rather than instructional.

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

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

With no annotations, the description carries the full burden, but it does disclose the async task model and that it returns a task id, status, and output URLs — meaningful behavioral context absent from any output schema. It omits permissions, cost/rate limits, failure behavior, and that the task id is meant to be consumed by get_task, leaving notable gaps for a 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler, and the action is front-loaded before the return-value note. It is efficient, though so sparse that it borders on under-specification rather than exemplary 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?

For a 12-parameter generation tool with no annotations and no output schema, the description is thin: it doesn't mention the timeout_ms/poll_interval_ms behavior, the fact that reference_image_urls is rejected by this model, or the handoff to get_task. The return-value sentence is the only substantive addition.

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 83%, so the schema already documents nearly all 12 parameters, and the description adds no parameter-level meaning at all. Baseline 3 per the rubric when schema coverage is high.

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?

States a specific verb and resource — 'Create a Grok Imagine task on RunAPI (text to video)' — which clearly separates it from image_to_video, text_to_image, and extend_video. It doesn't explicitly name those siblings, but the 'text to video' qualifier makes the scope unambiguous.

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 choose this tool over image_to_video or extend_video, nor any prerequisites (API key, credit cost) or advice on the wait/polling behavior. Usage is only inferable from the tool name.

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

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

With no annotations, the description carries the full burden. It helpfully discloses that this is an async task creation returning a task id, status, and output URLs, which is meaningful context. However, it omits permissions/auth, the meaning of the source_task_id, and — notably — does not reconcile the tool's image-upscale purpose with a parameter documented as accepting a prior *video* task ID.

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?

Two short sentences, front-loaded with the action and backend, with the return shape stated inline. Minimal waste, though '(upscale image)' is slightly redundant with the tool name.

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?

For a task-creation tool with no annotations and no output schema, the description usefully covers the return values. It is still thin on behavioral contract — async semantics, source_task_id requirements, and the image-vs-video inconsistency — so it is only partly complete.

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 60%, so the description should compensate, but it adds no input-parameter meaning at all. It says nothing about source_task_id, wait, timeout_ms, callback_url, or poll_interval_ms, leaving half the input contract 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?

States a specific verb (Create), a named operation (upscale image), and the backend (Grok Imagine task on RunAPI). This distinguishes it from siblings like edit_image and text_to_image, but it doesn't explicitly contrast with the closest alternative (edit_image), keeping it below 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?

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer this over edit_image or text_to_image. The parenthetical '(upscale image)' only restates the operation rather than routing the agent.

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