Skip to main content
Glama

Canva

by com.canva.mcp
OverviewDiscussionsAdmin

Get Design Text Content

get-design-content
Read-only

Extract rich text from an existing Canva design for read-only use.

Use to read the wording in a design, pull copy from selected pages, summarize a presentation or document, or quote text without making changes.

Not for rewriting, translating, correcting, or updating the text in a design. Does not return presenter notes, sheet cell data, or non-text design content. Returns the rich text content for every page, or specified pages of the selected design.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pagesNoOptional array of page numbers to get content from. If not specified, content from all pages will be returned. Pages are indexed using one-based numbering, so the first page in a design has the index value `1`.
design_idYesID of the existing Canva design whose rich text you want to retrieve, usually returned by a previous Canva tool. You can also provide a full Canva design share URL exactly as received; this preserves any collaboration token needed for access. Resolve Canva shortlinks before using this field.
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).
content_typesYesTypes of content to retrieve. Currently, only `richtexts` is supported so use the `start-editing-transaction` tool to get other content types

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / design_id / description
      Previous value: -"ID of the design to get content of, or a full Canva design share URL"New value: +"ID of the existing Canva design whose rich text you want to retrieve, usually returned by a previous Canva tool. You can also provide a full Canva design share URL exactly as received; this preserves any collaboration token needed for access. Resolve Canva shortlinks before using this field."
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with "for read-only use" and "without making changes." It adds behavioral exclusions beyond annotations: it does not return presenter notes, sheet cell data, or non-text content, and it returns content per page or specified pages.

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?

The description is compact and front-loaded with the core action, followed by use cases and exclusions. There is minor repetition of the read-only idea ("read-only use" and "without making changes"), but every sentence contributes useful guidance.

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

Completeness4/5

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

Given the tool's moderate complexity bugschema richness, the description covers purpose, scope, exceptions, and return scope. There is no output schema, but the description states that rich text for every page or specified pages is returned. No critical call-blocking information is missing.

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

Parameters3/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 design_id, pages, content_types, and user_intent in detail. The description adds no new parameter-specific meaning, but none is needed because the schema carries the burden completely.

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?

The description starts with a specific verb and resource: "Extract rich text from an existing Canva design for read-only use." It clearly distinguishes this from editing tools and from related retrieval tools by explicitly excluding presenter notes and non-text content, so an agent can tell it apart from siblings like get-presenter-notes and perform-editing-operations.

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

Usage Guidelines4/5

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

The description gives a clear "Use to" list (read wording, pull copy, summarize, quote) and a clear "Not for" list (rewriting, translating, correcting, updating). It does not explicitly name alternative sibling tools in the description text, but the when/when-not guidance is strong enough to steer an agent away from misuse.

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

All Canva toolsInspect
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