Skip to main content
Glama

Get Create Design Job

get-create-design-async-job
Read-only

Gets the status and result of a design generation job started by create-design. Pass the job_id and continuation_token from the previous create-design or get-async-job response. While the job is still running, wait the number of seconds the response's polling_policy.wait_seconds gives, then poll again with the same job_id and the updated continuation_token. Never poll sooner than that: it returns the same answer and the design arrives no earlier. Follow the polling_policy.instructions in every response, and relay them to the user while they wait. When the job completes, share the design link with them.

When the completed response carries design.print.is_printable as true, and you are replying in text alone — no UI surface of your own rendering the design — then alongside the design link tell the user they can also order this design as a physical print with Canva Print and share design.print.print_url. Otherwise say nothing about printing: when print is absent or is_printable is false, there is nothing to do and nothing to relay. Never tell the user a design cannot be printed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYesThe job_id returned by create-design. This value is stable and never changes.
user_intentNoMandatory 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).
continuation_tokenYesThe continuation_token from the most recent create-design or get-create-design-async-job response.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
designNoThe generated design. Only present when the job completed.
job_idYesID of the design generation job. Stable across all responses.
statusYesStatus of the job. While 'pending' or 'in_progress', poll again with the same job_id and the updated continuation_token after waiting polling_policy.wait_seconds. 'completed' carries the design; 'failed' carries the failure. 'polled_too_early' means you called before the wait window elapsed — wait polling_policy.wait_seconds, then poll again with the same job_id and continuation_token.
failureNoWhy the job failed. Only present when status is 'failed'.
polling_policyNoHow and when to poll next. Only present while the job is still running or when polled too early.
continuation_tokenNoOpaque token to pass on the next poll. Present while the job is still running or when polled too early. Always use the most recent token.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / failure / properties / code / description
      Previous value: -"Why the job failed. 'moderation_blocked' means the brief or a reference was declined by content moderation - tell the user and do not retry the same input. 'quota_exceeded' means the user is out of AI credits. 'throttled' means too many requests - retry later. 'invalid_input' will not succeed on retry without changing the request."New value: +"Why the job failed. 'moderation_blocked' means the brief or a reference was declined by content moderation - tell the user and do not retry the same input. 'feature_disabled' means design creation has been disabled by the user's admin - ask the user to contact their admin to enable it before trying again. 'quota_exceeded' means the user is out of AI credits. 'throttled' means too many requests - retry later. 'invalid_input' will not succeed on retry without changing the request."
    • changedOutput schema / properties / failure / properties / code / enum
      Previous value: -[
      -  "moderation_blocked",
      -  "quota_exceeded",
      -  "throttled",
      -  "invalid_input",
      -  "internal_error"
      -]New value: +[
      +  "moderation_blocked",
      +  "feature_disabled",
      +  "quota_exceeded",
      +  "throttled",
      +  "invalid_input",
      +  "internal_error"
      +]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only establish it is a safe read. The description goes well beyond that: it discloses the polling cadence contract, the requirement to relay polling_policy.instructions to the user, and precise conditional rules for exposing print.is_printable/print_url versus staying silent. This is rich, non-obvious behavioral context.

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?

Front-loads the core polling purpose in the first sentence and keeps sentences purposeful. The print conditional block is dense and long but each clause carries actionable logic, so it earns its space despite the overall length.

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?

With an output schema present, return values need not be explained, and the description instead supplies the missing operational contract: polling intervals, instruction relaying, and the exact print-eligibility branch. Nothing an agent needs to poll and report correctly is absent.

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 description coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that continuation_token must be the updated value from the most recent response and that job_id is stable, which is useful sequencing context 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 and resource ('Gets the status and result of a design generation job') and names the originating sibling, create-design. An agent can distinguish this polling tool from create-design or other get-* jobs 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.

Usage Guidelines5/5

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

Explicitly defines the call sequence: pass job_id and continuation_token from the previous create-design/get-async-job response, wait polling_policy.wait_seconds, then re-poll with the updated token. It also states a negative rule ('Never poll sooner') and routes print behavior conditionally, so the when/when-not is fully specified.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources