Canva

Get Generate Image Job

get-generate-image-job

Read-onlyIdempotent

Check an image generation job started by generate-image. When the generate-image UI widget is shown, the widget calls this tool itself and displays the image - do not call it yourself. Only when no widget is shown, pass the jobId returned by generate-image. If the status is PENDING, wait before polling get-generate-image-job again with the same jobId. Continue polling until the status is SUCCESS or FAILURE. Do not start a replacement generation job merely because the existing job is still pending, unless the user explicitly requests another generation. If the status is SUCCESS, use the generated image in result, present the returned image resource to the user, and include the returned Canva upload link as a Markdown link using the exact link text "Open generated image". The link opens the generated image in Canva, not the Canva editor. If the status is SUCCESS but the response says the image link is not ready yet, wait and call this tool again with the same jobId. Never finish a successful image-generation request without including the returned "Open generated image" link in the user-facing response, even when an inline image preview is visible. If the status is FAILURE, stop polling and explain the failure using failureType and failureMessage.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`jobId`	Yes	The jobId returned by the tool that started the job.
`user_intent`	No	Mandatory description of what the user is trying to accomplish with this tool call. This should always be provided by LLM clients. Please keep it concise (255 characters or less recommended).

Output Schema

TableJSON Schema

Name	Required	Description
`result`	No
`status`	Yes	PENDING while the job is still running, then SUCCESS or FAILURE.
`failureType`	No	Why the job failed. Only present when status is FAILURE.
`failureMessage`	No	Human-readable failure detail. Only present when status is FAILURE.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 28, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavioral context beyond them: the polling cadence, the widget self-invocation caveat, the retry-when-link-not-ready case, and the required user-facing output formatting. This is real operational guidance the schema cannot express.

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?

Long, but nearly every sentence carries non-redundant behavioral instruction (widget handling, polling, output formatting). Front-loaded with the core purpose. Slightly repetitive around the 'Open generated image' requirement, which is reinforced twice, costing a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a status-polling tool with an output schema, annotations, and a fully documented schema, the description covers the genuinely ambiguous parts – when to call, how to poll, and how to render results. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description goes further by tying jobId to its origin (returned by generate-image) and requiring the same jobId be reused across polls, which adds sequencing semantics the schema alone does not convey.

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?

States a specific verb+resource: checking the status of an image generation job started by generate-image. It clearly distinguishes itself from the sibling generate-image (which starts jobs) and from other job-status tools like get-create-design-async-job.

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

Usage Guidelines5/5

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

Extremely explicit routing rules: do not call when the UI widget is shown; call only when no widget is shown and pass jobId from generate-image; poll while PENDING; stop on SUCCESS or FAILURE; do not start a replacement job unless the user asks. When/when-not/alternatives are all covered.

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

All Canva tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?