Canva

Autofill Design

autofill-design

Destructive

Merge structured text, image, video, or chart values into named autofill fields to populate a Canva design, either as a new design or by overwriting an existing one in place. Use to merge a dataset or spreadsheet; place supplied names, details, or media into template placeholders; populate an existing design; or refill a design whose merged content is out of date.

Only use after you have identified a Brand Template or existing Canva design and confirmed it has fillable data fields. Only overwrite an existing design in place when the user has asked to refill that design rather than create a new one, since the overwrite replaces its content and cannot be undone. Not for creating a blank Brand Template copy.

Requires exactly one source and data that matches its field schema. Returns the populated design's design_id.

Input Schema

TableJSON Schema

Name	Required	Description
`data`	Yes	Values to merge into the source's autofill fields. Each key must exactly match a field name in the selected source's schema, and each value must use that field's expected type.
`title`	No	Title for the new populated design. Omit to keep the source title. Ignored when `update_in_place` is true, since the design keeps its own title.
`design_id`	No	ID of the existing Canva design to autofill, and the design overwritten when `update_in_place` is true. Only provide this after confirming the design has fillable data fields. Provide this or `brand_template_id`, not both.
`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).
`update_in_place`	No	Overwrite `design_id`'s existing content with the merged values instead of creating a new design. Defaults to false. Only valid alongside `design_id`, and only available to some accounts; where it is unavailable the call fails and a new design has to be created instead.
`brand_template_id`	No	ID of the Brand Template to autofill. Only provide this after confirming the template has fillable data fields. Provide this or `design_id`, not both.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantive context beyond them: the overwrite 'replaces its content and cannot be undone,' update_in_place is only available to some accounts and fails elsewhere, and exactly one source is required. This meaningfully enriches the safety and availability profile the annotations only gesture at.

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-loaded with the core action, then usage, prerequisites, and return value in three tight paragraphs. Every sentence carries weight, though the dense multi-clause sentences are slightly heavy for the size of the operation.

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?

For a complex mutation tool with nested objects and no output schema, the description covers prerequisites, source exclusivity, destructive in-place behavior, account limitations, and the return value (design_id). 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 description coverage is 100%, so the schema already documents each parameter, giving a baseline of 3. The description adds a genuine cross-parameter constraint ('Requires exactly one source') and data/schema-match requirement that the per-parameter schema text does not express, lifting it above 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?

States a specific verb+resource: merge structured text/image/video/chart values into named autofill fields to populate a Canva design. It clearly distinguishes itself from siblings like create-design, create-design-from-brand-template, and copy-design by framing the operation as field-based merge rather than design creation.

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 enumerates when to use (merge a dataset/spreadsheet, place placeholders, populate an existing design, refill stale content), states the prerequisite (identify a Brand Template or design and confirm fillable fields), and gives a when-not-to-use exclusion ('Not for creating a blank Brand Template copy') plus the condition governing the in-place overwrite.

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?