Canva

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

The description goes beyond the destructiveHint annotation by stating that unsaved changes are permanently lost and the transaction_id can no longer be used. It also mentions the return behavior ('confirmation that the changes were discarded'), which is useful since there is no output schema.

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 short, front-loaded with the core action, and every sentence adds relevant information. There is no filler or repetition beyond what is needed for clarity.

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 cancellation tool with a destructive annotation, the description covers what happens, the side effect on transaction_id, and the confirmation return. With no output schema, a bit more detail about the confirmation response could be useful, but the current description is sufficient for an agent to invoke the tool safely.

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 100%, so the schema already explains transaction_id and user_intent. The description adds only minor context by calling the transaction 'active' and noting the ID comes from the start operation, but it does not materially improve parameter understanding beyond the schema.

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 action ('Undo or discard all unsaved changes') and the specific resource ('active Canva editing transaction'). It also signals the opposite of saving, which differentiates it from the sibling commit-editing-transaction without needing to open that tool.

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 explicitly says when to use the tool: 'cancel a set of in-progress edits or finish editing without saving.' It does not name the commit sibling as the alternative for saving, but the context is clear enough for an agent to choose correctly.

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?

Annotations only state readOnlyHint=false and destructiveHint=false. The description adds that the comment is visible to all design collaborators and that the call returns the created comment and comment_id, which is important side-effect and outcome information. It could mention permission requirements, but this is adequate.

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 compact and front-loaded with the core action, followed by use cases, visibility, and return value. Every sentence adds useful information without redundancy.

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 create tool with no output schema, the description covers main use cases, visibility, and return shape. A small gap is the absence of explicit guidance to use reply-to-comment when the user is responding to an existing comment, and it doesn't resolve the user_intent 'mandatory' wording in the schema.

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%, and all three parameters have their own descriptions, so the tool description doesn't need to elaborate on them. It adds no new parameter semantics beyond implying the comment body is message_plaintext; baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Leave a new comment on an existing Canva design.' It also clarifies scope by saying 'new comment' and 'visible to everyone who has access,' which distinguishes this top-level comment action from sibling tools like reply-to-comment.

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?

It explicitly lists when to use the tool: giving feedback, asking a question, flagging an issue, or adding context for collaborators. It doesn't mention exclusions or direct the agent to reply-to-comment for responses to existing comments, so it falls short of full alternative routing.

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?

Annotations already flag destructiveHint: true, so the description adds value by disclosing the concrete consequences: 'apply all draft changes to the design, closes the editing transaction, and makes its transaction_id invalid.' It also mentions return behavior ('Returns confirmation'). This goes beyond the annotation without contradicting it.

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?

Four sentences, each earning its place: purpose, use case, approval requirement, and operational effect. Front-loaded with the main action. No redundancy or filler.

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 destructive mutation with two well-documented parameters and no output schema, this description covers purpose, usage gating, behavioral consequences, and return confirmation. It could mention error scenarios (e.g., already-closed transaction) but that is a minor omission given the clarity provided.

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 100% with clear descriptions for both parameters: transaction_id is 'Exact ID of the active editing transaction' and user_intent is described. The description adds no new parameter-specific details beyond restating that the transaction is active and that the id becomes invalid—context already implied by the schema's phrasing. Baseline 3 is appropriate.

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 ('make permanent'), resource ('all draft changes in an active Canva editing transaction'), and scope ('text, layout, or media updates'). Clearly distinguishes from sibling cancel-editing-transaction by describing the permanent save action and from start-editing-transaction by implying an existing transaction.

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?

Explicitly instructs when to use it ('to save a completed set of edits') and provides a mandatory precondition: 'Show the user a preview of the design and obtain their explicit approval before calling this tool.' This gives the agent clear decision and action guidance, including a human-in-the-loop step.

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?

Annotations are all false with no hints about effects, so the description carries the burden. It clearly states that the tool creates a new design, leaves the source unchanged, and returns the new design_id. This meaningfully explains the behavioral outcome beyond the schema.

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 concise and well-structured: the core action is in the first line, usage scenarios follow, and the key side-effect/result is stated last. Every sentence earns its place with no filler.

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 low-complexity tool with a fully documented schema and no output schema, the description covers what the tool does, when to use it, what it creates, the source immutability, and the returned design_id. Nothing essential is missing for correct invocation.

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 the schema already documents design_id and page_numbers thoroughly. The description adds a small hint by mentioning 'copy selected pages', but does not go beyond the schema's explicit parameter documentation.

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 uses a specific verb ('Duplicate') and resource ('existing Canva design'), and explains the page-selection variation. It distinguishes itself from siblings by explicitly stating it is not for combining pages from more than one design, setting it apart from merge-designs.

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 explicitly lists when to use the tool: making a separate working copy, cloning, forking, backing up, or preserving the original. It also gives clear exclusion criteria: single source design only and not for combining pages from multiple designs.

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?

Annotations already indicate this is a mutating operation (readOnlyHint=false, destructiveHint=false), so the description doesn't need to restate that. The description adds useful context about page selection and the direct-call behavior, but it doesn't disclose what happens if the template ID is invalid, whether the design is created in a specific folder, or what the response contains. With annotations covering the basic safety profile, a 3 is appropriate.

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 compact and front-loaded: the core action is stated first, followed by the optional behavior, then the routing guidance. Every sentence earns its place, and the guidance is actionable without being verbose.

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 creation tool with no output schema, the description covers the main decision points: when to call directly, when to search, and when to use autofill. It doesn't describe the return value or error cases, but the routing guidance and parameter semantics are strong enough that an agent can invoke the tool correctly in most scenarios.

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 the schema already documents all three parameters. The description adds context for `page_numbers` (optional, 1-based, omit for all pages) and `brand_template_id` (direct-call behavior), but it doesn't add meaning beyond what the schema already provides. Baseline 3 is correct.

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 ('Create') and resource ('a new Canva design from a brand template'), and explicitly distinguishes itself from the sibling `search-brand-templates` and `autofill-design`. It also clarifies the optional page selection behavior, making the tool's purpose 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?

The description provides explicit when-to-use guidance: call directly when a brand template ID is already known, do NOT call `search-brand-templates` first, and use `autofill-design` instead when custom data needs to be filled. This is strong routing guidance that leaves little to inference.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is covered. The description adds context beyond annotations: the create-then-edit sequential workflow (call this first, then use returned design_id with start-editing-transaction and editing tools), and the requirement to obtain candidate_id from generate-design results. It does not contradict the annotations.

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 longer than average but every block earns its place given the complex routing requirements. The 'LEGACY-ONLY' warning and brand exception are front-loaded before the core workflow. Slight redundancy exists (the DO NOT CALL constraint is stated twice), and the routing block could be tightened, but the structure is effective and information-dense rather than padded.

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 tool in a 33-sibling ecosystem with no output schema, the description handles the return value itself ('design summary containing a design ID') and the cross-tool sequencing with generate-design and start-editing-transaction. One minor gap: the routing condition references create-design, which is not actually present in this tool list — the conditional is somewhat hypothetical here, though the description does gracefully state it applies 'when create-design is absent from the tool list.'

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 100%, so the baseline is 3. The description adds value beyond the schema by explaining the provenance of both job_id and candidate_id ('returned in the generate-design response') and the ordering requirement linking them to the generate-design pipeline. This ties each parameter to its upstream source, which the schema alone does not convey.

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 new Canva design from a generation job candidate ID' — and clarifies the mechanism: 'converts an AI-generated design candidate into an editable Canva design.' This distinguishes it from generate-design (which produces candidates) and create-design-from-brand-template (brand-templated variants), so an agent can separate it from siblings without opening schemas.

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?

Exceptionally explicit routing: it names the preferred alternative (create-design), forbids calling this tool when that alternative is present, and carves out a precise brand exception ('brand kit, brand colours, fonts or logo, brand template'). It also notes that a failed create-design call does not make this tool available. This is textbook when-to-use vs when-not-to-use guidance.

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?

Annotations already indicate this is a non-read-only, non-destructive mutation. The description adds useful behavioral context by stating that it returns the new folder including its folder_id. It does not discuss permissions or edge cases, but the annotation coverage lowers the burden.

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 concise and front-loaded with the core action. The use-case sentence adds value, though 'keep designs, images, and folders together' slightly overlaps with 'organise related work'. Overall, every sentence earns its place.

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 create operation, the description covers purpose, use cases, and the return value. Since there is no output schema, mentioning the returned folder_id is helpful. The 'root' special value for parent_folder_id is already covered in the schema.

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 the parameters are already well documented. The description does not add significant parameter-level meaning beyond what the schema provides, which makes the baseline score of 3 appropriate.

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 uses a specific verb and resource: 'Create a Canva folder'. It clearly states the purpose ('organise related work') and is distinct from sibling tools like search-folders, list-folder-items, and move-item-to-folder.

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?

It provides clear context for when to use the tool: setting up a project folder, adding a subfolder, or keeping related items together. It does not explicitly name alternatives or exclusions, but the use cases are specific enough for an agent to select it correctly.

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?

Discloses non-obvious behavior well beyond annotations: URL is single-use, expires after a short period, must be consumed with a raw octet-stream POST, must not be retried, and returns resource IDs. This is exactly the kind of operational detail an agent needs and annotations do not provide.

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?

Well-structured and front-loaded, with a clear purpose statement followed by Step 1/Step 2 instructions. The first sentence is somewhat long with enumerations, but every part contributes useful guidance for correct invocation.

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?

Covers the full workflow: call this tool, POST raw bytes, handle the response, retry policy, and exclusion of public-URL files. The presence of an output schema means return-value details need not be spelled out, and the description still mentions resource IDs returned by the POST.

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?

The only parameter, user_intent, is fully documented in the schema with 100% coverage, so the description does not need to repeat it. The description adds context about the broader workflow, but not parameter-level meaning beyond the schema.

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 concrete action: creating a single-use upload URL for files whose bytes the user can access, then uploading those bytes to Canva. It clearly distinguishes itself from URL-import alternatives, which are for files already at a public URL.

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?

Explicitly says when to use this tool ('when the user wants to add, upload, import, or send a file they have') and when not to ('for a file already at a public URL, prefer a URL-import tool'). It also provides retry guidance, which is essential for correct use.

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?

Annotations already mark this as readOnly and non-destructive, and the description does not contradict them. It adds useful context by stating that the operation returns a download URL and requires prior format-support confirmation, but it does not disclose async behavior, rate limits, or other side effects beyond the annotation-covered safety profile.

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 three short, front-loaded paragraphs: purpose, when-to-use, and precondition/return behavior. Every sentence adds distinct information without redundancy or filler.

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 export tool with no output schema, the description covers the core outcome (download URL), the key precondition, and representative use cases. It does not address failure modes or asynchronous timing, but the schema carries parameter-level detail, making this sufficient for a 3-parameter tool.

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%, and every parameter (design_id, format, user_intent) along with the nested format fields has a descriptive entry in the input schema. The tool description does not repeat or add parameter 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 names a specific verb and resource ('Export an existing Canva design as a downloadable file') and enumerates concrete use cases: printing, emailing, sharing, converting, or downloading selected pages. This clearly distinguishes it from sibling tools like get-design or get-design-pages, which retrieve design data rather than produce a downloadable artifact.

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?

It provides explicit 'Use when...' conditions covering five concrete scenarios and a hard precondition: 'Only call after you have confirmed that the selected design supports the requested format.' It does not name alternatives or explicit when-not-to-use cases, so it stops short of a 5.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, which the description supports by clarifying that generated designs are non-persistent candidates until create-design-from-candidate is called. It adds critical behavioral context: no context between calls, latency tradeoffs, error handling, and the requirement to provide detailed query context. Does not contradict annotations.

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 long, but every section earns its place: the legacy warning is front-loaded, usage is clarified early, and the presentation format is essential structured detail. The use of headers and numbered steps keeps it navigable despite length. Not excessively verbose for the tool's complexity.

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?

Given 7 parameters, many design types, and a complex presentation format, the description is remarkably complete. It explains the full lifecycle (candidate generation → selection → create-design-from-candidate), error handling, asset ordering, verbatim mode, brand kit flow, and even a quality checklist for presentations. No output schema exists, so the description's explanation of what it returns ('list of generated design candidates, including a candidate ID, preview thumbnail and url') fully compensates.

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 has 100% coverage of all 7 parameters with descriptions, so the baseline is 3. The description adds extra semantic nuance beyond schema: ordering of asset_ids, verbatim handling specifics, mandatory user_intent, and the requirement to ask before using brand_kit_id. This elevates it above bare schema reliance.

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 ('Generate professionally designed content in Canva') and resource, and immediately distinguishes itself from create-design via the LEGACY-ONLY and brand exception. The description clearly identifies both visual and text-based designs, making it impossible to confuse with siblings like import-design-from-url.

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?

Explicit, actionable guidance: says when to call (whenever user asks to write/create/generate/draft), when NOT to call (create-design available, prepare-design-generation, URL import, advice-only requests), and lists concrete examples mapping user phrasing to this tool. Also covers the brand-kit exception precisely.

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?

Annotations already convey readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it guarantees 'Returns the metadata and thumbnail for each item in the same order as the supplied asset_ids,' which informs the caller about output ordering. This is a meaningful behavioral trait not implied by the schema or annotations.

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 compact yet comprehensive. It opens with the core purpose, then the usage context, then exclusions, and finally the return behavior. Each sentence earns its place without redundancy, making it easy for an agent to parse quickly.

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?

Without an output schema, the description must delineate the return value. It states the tool returns metadata and thumbnails and preserves input order, which covers essentials. While it does not enumerate each metadata field in the response structure (e.g., exact JSON shape), it lists the fields in the opening sentence. Given the tool's read-only nature and the schema's thorough parameter descriptions, it is sufficiently complete for correct invocation.

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%, and the schema already provides detailed descriptions for both parameters. 'asset_ids' includes guidance on usage ('When checking which media is the target on a page, include every image and video ID from that page'), and 'user_intent' is clearly mandatory. The description adds little beyond the schema, so a baseline score of 3 is appropriate.

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 explicitly states the resource (images and videos in a Canva design) and the exact fields returned (names, tags, types, creation dates, thumbnails). It also differentiates from siblings by stating it is 'Not for design metadata or editing the media itself,' making it distinct from get-design-content 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.

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

The description provides clear usage context: 'Use when you need to check which image or video is the target on a page, look up its details, or preview it before changing it.' It also gives exclusions: 'Not for design metadata or editing the media itself.' However, it does not explicitly name alternative tool names (e.g., get-design-content or perform-editing-operations), so the guidance is strong but not fully explicit about alternatives.

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?

Annotations already state readOnlyHint and destructiveHint, so the description correctly avoids repetition. It adds value by disclosing return behavior ('Returns each field's name and data type') and the edge case ('An empty object means...'). It also states the requirement for a brand_template_id, though the param name mismatch with schema is a minor flaw.

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 organized into three short paragraphs: purpose, usage, and return details. It is front-loaded with the core action and avoids excessive fluff, though the second paragraph could be merged with the first for tighter structure.

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 tool with one required param, the description covers the return format and the empty-object case. It also clarifies scope ('Not for an individual existing design'). The only notable gap is the param name inconsistency ('brand_template_id' vs 'template_id'), which could confuse an agent.

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 the schema fully documents both parameters. The description adds no additional parameter-level meaning beyond restating that 'brand_template_id' is required, which actually conflicts with the schema's 'template_id' naming. This does not improve on schema coverage.

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 ('Determine... list') and resource ('Brand Template'). It explicitly differentiates from sibling tools by noting 'Not for an individual existing design,' which sets it apart from get-design and similar tools.

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 provides clear usage scenarios ('Use to check if the template can be populated with data...') and an exclusion ('Not for an individual existing design'). It does not name a specific alternative sibling, but the guidance is sufficient to route the agent appropriately.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context: it returns metadata and access links only, does not summarize content, and does not provide per-slide thumbnails. This goes beyond the annotations by clarifying the scope of what the tool can and cannot do, while remaining consistent with the read-only nature.

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 well-organized and front-loaded: it starts with what is returned, then gives usage scenarios, then explicit exclusions. It is slightly verbose in repeating the metadata list and final 'Returns metadata' line, but every sentence earns its place and the structure aids comprehension.

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?

With no output schema, the description compensates by enumerating the returned fields (type, title, owner, links, thumbnail, timestamps, page count) and explicitly stating limitations. It lacks details on error conditions or permission requirements, but for a read-only lookup tool with rich annotations and sibling context, this is adequate.

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%, with the schema already providing detailed semantics for design_id (including URL acceptance and shortlink caveat) and user_intent. The description adds minimal parameter-level meaning beyond 'one existing Canva design,' so the baseline of 3 is appropriate since the schema carries the parameter documentation burden.

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 action ('Look up the record for one existing Canva design') and explicitly enumerates the metadata returned: design type, title, owner, links, thumbnail, timestamps, page count. It also distinguishes itself from siblings by explicitly stating it is not for folders, image assets, text content, or per-slide thumbnails, which clearly separates it from get-design-content, get-design-pages, and get-design-thumbnail.

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 clear use cases ('open a specific design, find out who created it, check when it was last changed, or see how many pages it has') and explicit exclusions ('Not for folders or image assets. Do not use for reading or summarizing a design's text or for per-slide thumbnails'). It does not name the specific sibling tools to use instead, but the guidance is clear enough for correct selection.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds only the vague notion of 'widget UI polling' without explaining polling semantics, repeated-call expectations, status behavior, or what the response represents.

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 short but under-specified, not concise in a useful way. 'Internal tool' is filler, and the single sentence does not convey enough information to justify its brevity.

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?

With no output schema, the description needed to explain what design candidates are, how they relate to generate-design, and what the tool returns. It does none of this, leaving the agent to guess the tool's purpose and expected response.

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 the schema already documents job_id and user_intent. The description adds no parameter-specific meaning, but the baseline of 3 is appropriate because the schema carries the burden.

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, 'Internal tool for widget UI polling,' is vague and does not state that the tool retrieves design candidates. It offers no specific verb plus resource, and it fails to differentiate itself from sibling tools like generate-design or create-design-from-candidate.

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 use this tool versus alternatives. It does not mention that it should be used after generate-design or before create-design-from-candidate, and it lacks any exclusions or alternative routing.

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?

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.

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.

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.

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.

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.

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.

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

Annotations already mark the tool read-only and non-destructive, and the description adds valuable behavioral context beyond that: thumbnails do not reflect uncommitted editing-transaction changes, only the requested pages are returned, and the total page count is not included. This sets accurate expectations without contradicting the annotations.

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 front-loaded with the core action, followed by use cases, exclusions, and return limitations. Every sentence earns its place, and there is no redundant restating of the tool name or title.

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 read-only list operation with no output schema, the description sufficiently explains what the agent will get (page index and thumbnail), what it will not get (total page count), and when it is not appropriate. Combined with fully documented parameters and annotations, the agent has enough context to call it correctly.

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 the parameters are already well documented; the description adds little parameter-specific detail beyond the notion of ranges and requested pages. Per the baseline for full schema coverage, a 3 is appropriate.

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 opens with a specific verb and resource: 'List the pages in an existing Canva design' and specifies the returned content (page index and thumbnail). It clearly distinguishes itself from sibling get-design-thumbnail by focusing on per-page previews, and it narrows applicability with 'Canva Docs do not have pages.'

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?

It provides explicit use cases ('browse a design's pages or slides, see each page thumbnail in order, show what a specific page looks like, or get a range of page previews') and explicit exclusions ('Do not use to retrieve a thumbnail that reflects uncommitted changes...' and 'Canva Docs do not have pages'). This tells an agent when to choose the tool and when to avoid it.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds valuable behavioral context: one-call-per-page, dependence on an editing transaction, and the non-negotiable instruction to show every thumbnail preview to the user. No contradiction with annotations exists.

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 front-loaded with the core purpose and keeps the needed operational details in a compact sequence. The all-caps emphasis is redundant in wording but serves a real functional purpose, so the length remains justified.

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?

The description covers the prerequisite workflow, the one-page-per-call constraint, and the required user-facing display behavior. It does not describe the exact response payload, but the absence of an output schema is mitigated by the clear instruction to show the returned thumbnail preview.

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?

The input schema already provides full descriptions for transaction_id and page_index, including the one-based indexing rule and the exact source of the transaction ID. The description mostly restates these requirements without adding deeper semantic meaning 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 clearly states the resource and action: getting the thumbnail for a specific page of a design within an editing transaction. It distinguishes this from sibling tools like get-design-pages or get-design by focusing specifically on thumbnail retrieval tied to a transaction ID and page index.

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 explicitly specifies the prerequisite of using start-editing-transaction to get the transaction ID, and clearly states that each call retrieves one page's thumbnail. It does not name alternatives or exclusions, but the context is unambiguous and actionable.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context: this is a preflight check that returns supported formats and available pages rather than performing the export itself.

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 compact, front-loaded with the core action, and every sentence adds useful information: what the tool checks, when to use it, and what it returns. No wasted words.

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 query tool with no output schema, the description covers the key facts an agent needs: what it checks, when to invoke it, and what it returns. More detail about the exact response shape would be nice, but it is not necessary for correct selection and invocation.

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 the schema already documents design_id and user_intent. The description only lightly reinforces that the design must exist, adding little beyond the structured parameter definitions. This meets the baseline for high schema coverage.

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 uses a specific verb ('Check') and identifies a clear resource: export file types supported by an existing Canva design, including page availability. It also lists concrete formats (PDF, PNG, JPG, GIF, PowerPoint, video, CSV), which clearly distinguishes this look-up tool from siblings like export-design or get-design-pages.

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 explicit context: use it to confirm downloadability before creating/exporting a file. It does not explicitly name alternatives or state when not to use it, but the timing and purpose are clear enough to guide tool selection.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond annotations: that only the separate notes are returned, not slide content, and that results cover every page or only requested pages. No contradiction with annotations exists.

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?

Three tightly organized paragraphs: purpose first, use cases and exclusions second, return behavior last. Every sentence earns its place, and the most decision-relevant information (read-only, scope boundary) is front-loaded. No filler or repetition of schema details.

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 read-only retrieval tool with a single required parameter and no output schema, the description covers what the agent needs: the target resource, the return scope (notes per page), and how to limit to specific pages. Minor omissions like behavior when a slide has no notes or note format are acceptable given the tool's simplicity and supporting annotations.

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%, with all three parameters (design_id, pages, user_intent) already documented, including one-based page numbering and default all-pages behavior. The description's final sentence reinforces the pages semantics ('from every page, or the specified page numbers') but adds little beyond what the schema already provides, 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 states a specific verb and resource ('Get presenter notes from an existing Canva presentation') and explicitly differentiates from siblings with 'Not for reading the presentation itself; this only returns the separate notes attached to each slide.' This unambiguously separates it from get-design, get-design-content, and get-design-pages without needing to open their schemas.

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 clear when-to-use scenarios ('reviewing speaker notes, pulling talking points for particular slides, or summarizing notes across a presentation') and an explicit exclusion ('Not for reading the presentation itself'). It stops short of naming the specific alternative tool to use for presentation content, so it misses full 5-level routing, but the boundary is clear.

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?

Annotations indicate readOnlyHint=false and destructiveHint=false, but do not explain creation semantics. The description adds that 'Each call creates one design and returns its design_id,' which is valuable behavioral context. It also discloses the limitation regarding flat images, helping the agent set expectations. No contradiction with annotations.

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 front-loaded with the core action, followed by supported formats, exclusions, and return behavior. Each sentence serves a purpose: scope, eligibility, counter-indications, and outcome. No redundancy or fluff.

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 creation tool with no output schema, the description covers what the agent needs: supported inputs, key constraints, creation count, and return value (design_id). The input schema supplements with detailed URL and format parameters. Together the definition is complete enough to invoke correctly.

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 the schema already documents all four parameters, including the detailed URL constraints and enum options. The description itself adds little param-specific detail, but it does reinforce the public-URL restriction. Baseline 3 applies because the schema carries the semantic burden.

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?

Begins with a specific verb and resource: 'Convert content at a public URL into a new Canva design.' It names the exact domain (public HTTPS sources) and the artifact (a new Canva design), and enumerates supported file types. This clearly separates it from sibling creation tools like generate-design or create-design-from-brand-template, which use different sources.

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?

Explicitly states when to use ('Use to turn a publicly hosted...') and when not to ('Do not use for local, private, or agent-generated files, or to break a flat PNG, JPEG, or WEBP'). This gives the agent unambiguous selection criteria without needing to infer from the schema. The 'Only call with a public HTTPS URL' constraint is direct and actionable.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: the results are limited to kits 'available to the user' and it states exactly what is returned (brand_kit_id, name, thumbnail). It does not discuss pagination, but the continuation parameter schema covers that.

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?

Five short, purposeful sentences. The core action is front-loaded, the domain definition earns its place, the exclusion is relevant, and the return shape is stated without redundancy.

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?

Despite having no output schema, the description names the returned fields. The tool is low-complexity, annotations cover the read-only/destructive profile, the sibling distinction is clear, and the input schema handles parameter semantics. Nothing essential is missing for correct invocation.

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 the baseline is 3. The tool description does not add parameter-level detail, but it doesn't need to because the schema already explains limit, user_intent, continuation, and resolve_icon_thumbnails clearly.

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 opens with a specific verb and resource: 'Find or browse the Canva Brand Kits available to the user.' It clearly defines what a Brand Kit is and explicitly contrasts with Brand Templates, so an agent can distinguish it from search-brand-templates and other siblings.

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 concrete reasons to use the tool: find a user's brand identity, check team brand elements, or identify the needed Brand Kit. It also provides an explicit exclusion ('Not for finding individual Brand Templates'), which semantically routes the agent toward the sibling search-brand-templates tool.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it returns replies and mentions and provides a continuation token for pagination. No contradiction with annotations exists.

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 three focused sentences with the primary action front-loaded, followed by concise use cases and return behavior. There is no filler or redundant repetition of schema details.

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 list operation with rich schema documentation and annotations, the description is largely complete: it states the resource, the use cases, return contents, and pagination behavior. The absence of an output schema makes the return-value summary especially useful, though ordering/filtering behavior is not mentioned but is not essential.

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 all four parameters are already documented in the schema. The tool description does not add significant parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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 ('Browse') and resource ('all comments or threads attached to an existing Canva design'), making the tool's function clear. It is distinguishable from mutating siblings like comment-on-design and reply-to-comment, though it does not explicitly name or contrast those alternatives.

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 clear use contexts: 'review feedback, see discussion points, or check mentions.' It does not explicitly state when to avoid this tool or prefer a sibling like list-replies, but the provided use cases are specific enough for an agent to select it appropriately.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond that: results are filtered ('matching items') and pagination is handled via a continuation token. This helps the agent understand multi-page behavior and that the response shape is a list, not a single object.

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?

Three short sentences with no filler. The core action is front-loaded in sentence one, usage context in sentence two, and the pagination behavior in sentence three. Every sentence earns its place and the description is easy to scan.

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 read-only browse tool, the description covers the essential decision points: what items are returned, when to use it, and how pagination works. With no output schema, some detail about the shape of returned items would be useful, but the annotation-provided safety profile and the clear continuation-token note make this adequate for an agent to call it correctly.

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 the baseline is 3. The description reinforces the item_types parameter by naming designs, folders, and images, and mentions the continuation token that maps to the continuation parameter, but it does not add new semantic meaning beyond what the schema already documents.

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 opens with a specific verb and resource: 'Browse the contents of a Canva folder to find designs, folders, and images stored in it.' This clearly states what the tool does and distinguishes it from sibling search tools like search-designs and search-folders, which find items across folders rather than browsing one known folder. The phrase 'stored in it' further narrows scope to a single folder's contents.

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 second sentence gives concrete use cases: 'review a project folder, locate an item in a known folder, or check its contents before organizing items.' This tells an agent when to reach for this tool, and 'known folder' implicitly contrasts with search tools for unknown locations. However, it does not explicitly name alternatives or state when not to use it, so it stops short of full differentiation.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description only needs to add value beyond safety. It does so by disclosing pagination behavior: returns the selected comment's replies and a continuation token when more results exist. This is useful behavioral context that annotations don't provide.

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?

Four short sentences, each earning its place: the action, the intended use, the exclusions, and the return/pagination behavior. No redundancy or filler.

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?

Despite having no output schema, the description states what is returned (replies and optional continuation token), and the schema documents all parameters and constraints. Nothing an agent needs to invoke this correctly is missing.

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 parameters are already fully documented. The description adds minimal extra meaning by referring to 'a specific comment thread' and the continuation token, but the schema already covers these concepts. Baseline 3 is appropriate.

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?

Description uses a specific verb ('read') and resource ('replies in a specific comment thread on a Canva design'), and explicitly differentiates from reviewing all comments or adding a reply. This cleanly separates it from siblings like list-comments, reply-to-comment, and comment-on-design.

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?

States exactly when to use it ('Use to see who has replied to a comment and what they said') and when not to ('Not for reviewing all comments attached to a design or adding a reply'). Though it doesn't name alternative tools, the use-case exclusions are explicit enough for an agent to route correctly.

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?

Annotations already include destructiveHint=true, and the description adds valuable context: 'Deleting pages is permanent' and 'Requires explicit approval for the exact requested operations before every call.' It also states the return behavior. No contradiction with annotations.

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 efficiently organized: main purpose first, then use cases, then warnings and exclusions, then return value. Every sentence earns its place and there is no repetition or filler.

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 tool with a rich input schema and no output schema, the description adequately covers scope, safety, exclusions, and the return value. It could go slightly further by naming the sibling tool for content edits, but the provided context is sufficient for correct selection and invocation.

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 the schema carries the parameter documentation burden. The description summarizes the operation types ('inserting or removing whole pages, or changing page order') but adds no parameter-level detail beyond that baseline.

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: 'Restructure a Canva design by combining designs, inserting or removing whole pages, or changing page order.' It clearly distinguishes page-level structural changes from content-level editing, so an agent can tell it apart from siblings like 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.

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

It provides concrete use cases: making a new presentation, adding slides, merging designs, rearranging flow, and removing pages. It also gives a clear exclusion: 'Not for changing text, images, or other content within a page.' It does not name an alternative sibling tool, but the when-to-use and when-not-to-use guidance is clear.

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?

Annotations already indicate non-read-only and non-destructive behavior. The description adds value by explicitly stating 'This changes the item's location' and 'Returns confirmation of the move,' which clarifies side effects and return behavior beyond what annotations provide.

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?

Three short sentences with no filler. The core action, use cases, side effect, and return value are all conveyed efficiently, and the most important information appears first.

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 three-parameter mutation tool with complete schema coverage and annotations, the description covers purpose, use cases, behavioral change, and return behavior. It is complete enough for an agent to call it correctly, though it omits potential edge cases like moving a folder into itself or the exact structure of the confirmation.

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 the schema already explains item_id, user_intent, and to_folder_id. The description reinforces that the tool moves designs, folders, or images and that 'root' means top level, but it does not add meaningful semantic detail beyond the schema.

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 uses a specific verb ('Relocate') with a clear resource ('existing Canva design, folder, or image') and destination ('destination Canva folder'). It is distinct from all sibling tools, none of which perform moving, so an agent can identify it unambiguously.

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 concrete use cases: 'filing, reorganizing, archiving, or returning an item to the top level.' This provides clear context for when to use the tool, though it does not explicitly name alternatives like copy-design or create-folder or state when not to use this tool.

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?

Annotations only mark the tool as read-write and non-destructive; the description adds crucial workflow semantics: changes are draft and temporary, explicit user approval is required before saving, and the response returns updated page state. This meaningfully extends beyond the structured annotations.

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 five short sentences with the core action front-loaded, a compact use-case list, an explicit exclusion, and workflow reminders about preview and approval. Every sentence earns its place with no filler or repetition.

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 complex multi-operation mutation tool with no output schema, the description gives the essential workflow context: active transaction, temporary unsaved changes, preview/approval requirement, and the returned updated page state. It appropriately relies on the fully covered input schema for parameter details.

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 the input schema already documents all parameters. The description adds high-level operation categories but does not provide additional meaning for specific parameters beyond the schema, which is acceptable given full coverage.

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 first sentence names the verb ('apply'), the resource ('existing Canva design'), and the scope ('within an active editing transaction'). The list of concrete uses and the 'Not for changing a design's page structure or order' negative make it easy to distinguish from related transaction tools.

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 explicitly states when to use the tool with 'Use to revise, rewrite, or translate text...' and clearly excludes page-structure changes. It also gives workflow guidance about previewing and obtaining approval before saving, though it does not name a specific alternative tool for the excluded cases.

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?

Annotations already establish that this is not read-only and not destructive. The description adds meaningful behavioral context beyond those hints: the reply is visible to everyone with design access, and the tool returns the created reply along with its comment_id. This helps the agent set expectations for side effects and output.

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 compact and front-loaded with the core action, followed by relevant use cases, visibility behavior, and return value. Every sentence contributes information the agent needs; there is no filler or repetition of the schema.

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, additive write operation, the description is complete: it states the action, the context in which to use it, the visibility side effect, and the return value. The remaining details, such as message length limits and design_id format, are already fully covered by the input schema.

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 the schema already documents all four parameters (design_id, comment_id, user_intent, message_plaintext). The description adds no parameter-specific details beyond referring to 'existing comment' and 'reply', so the baseline of 3 is appropriate.

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 opens with the specific verb 'Add' and the precise resource ('response to an existing comment in a Canva design'). This clearly distinguishes it from sibling tools like comment-on-design, which creates a new top-level comment, and list-replies, which only reads replies.

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?

It gives concrete use cases: answering a reviewer's question, acknowledging or clarifying feedback, continuing a discussion, and providing a follow-up. It does not explicitly name alternative tools or state when not to use this tool, but the 'existing comment' framing strongly implies the boundary against creating new comments.

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?

Beyond the annotations, the description discloses a key side-effect guarantee: each call creates a new resized design and leaves the original unchanged. It also states the return value ('Returns the new design's design_id'), which is especially useful because no output schema is provided.

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 compact and front-loaded: core behavior first, followed by usage conditions, an exclusion, and the return value. Every sentence earns its place without repeated 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 3-parameter tool with a fully documented schema, the description covers the input context, the exclusion case, the non-destructive behavior, and the return value. The missing output schema is mitigated by explicitly stating that the new design_id is returned.

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%, and the schema already documents design_id, design_type, preset/custom options, width, height, and user_intent. The description adds little beyond the schema, so the baseline of 3 is appropriate.

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 names a specific operation: 'Adapt a Canva design to a different canvas size' while keeping its content and rearranging/resizing the layout. It differentiates itself from copy-only or edit-only tools and explicitly excludes element-level resizing, so an agent can identify what the tool does.

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?

It provides a clear 'Use when' list with concrete triggering conditions, including different dimensions, aspect ratios, channel adaptation, and exact pixel sizes. It also states a clear exclusion ('Not for resizing a single element'), though it does not name a specific alternative sibling tool.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable context beyond annotations by explaining that the tool is a necessary prerequisite for other Canva tools and returns the full design URL. It doesn't contradict annotations; it enriches them with usage context.

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 concise (three sentences) and front-loaded with the core purpose. The usage guidance and prerequisite follow logically, and every sentence contributes actionable information without redundancy.

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 tool with one required parameter, the description fully covers the purpose, usage, prerequisite, and expected output (full URL). No critical information is missing for an agent to correctly invoke the tool.

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?

The schema has 100% description coverage for both parameters, so the description adds no additional meaning beyond what the schema already provides. The return format is mentioned in the description, but parameter details are fully covered by the schema, meeting the baseline for this dimension.

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 a specific verb ('turn') and resource ('Canva shortlink into the full Canva design URL'), making the tool's function unambiguous. It distinguishes itself from sibling design tools by focusing on URL resolution rather than design operations.

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?

Explicitly states when to use the tool ('Use when a Canva shortlink is shared and the linked design needs to be opened, read, edited, or otherwise worked with') and adds a critical prerequisite ('Shortlinks must be expanded before the linked design can be used with another Canva tool'). This gives clear guidance on when this tool is the appropriate choice.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it returns matching templates with brand_template_id, name, and preview thumbnail, and notes that some templates include data fields that can be autofilled. It doesn't describe pagination behavior in detail, but the continuation parameter covers that. Slight gap: no mention of rate limits or auth, but not critical for a read-only search 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?

The description is well-structured: a clear first sentence stating the core function, a when-to-use paragraph, a when-not-to-use paragraph, and a brief return-value statement. Every sentence earns its place, and the most important information is front-loaded. It's appropriately sized for a tool with 7 parameters and complex routing logic.

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 read-only search tool with 86% schema coverage and no output schema, the description is quite complete. It covers the tool's scope, exclusions, return values, and the key decision point about data fields. The only minor gap is that it doesn't explicitly state that results are paginated or that 'continuation' should be used for subsequent pages, but the schema's 'continuation' parameter description covers that. The description is complete enough for an agent to select and invoke this tool correctly.

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 86%, so the schema already documents most parameters well. The description adds value by explaining the 'dataset' filter's purpose (find templates to autofill) and the 'query' parameter's usage rule (only provide when user explicitly names/describes a template). The 'user_intent' parameter is described as mandatory for LLM clients, which is important context. The description doesn't add much for 'brand_kit_id' or 'continuation', but the schema covers those adequately.

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: find or browse Canva Brand Templates, and distinguishes it from related tools by specifying it works with Brand Templates, not existing designs. It names the resource (Brand Templates) and the action (search/browse), and explicitly contrasts with 'search-designs' and 'create-design-from-brand-template'.

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 provides explicit when-to-use guidance: when a Brand Template needs to be located, when a reusable starting point is needed, or when a template with data fields is needed before autofilling. It also gives explicit when-not-to-use guidance: not for existing designs, not for creating new designs without a template source, and not for creating/updating/populating an already selected template. This is exemplary.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds valuable behavioral detail about pagination via a 'continuation token' and explains that results include enough information to act on a specific design, which goes beyond the structured annotations.

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 compact and front-loaded: purpose in the first sentence, usage in the second, exclusion in the third, and return behavior in the fourth. No filler or redundant statements; every sentence earns its place.

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 read-only search tool with 100% schema coverage and no output schema, the description is complete: it explains what is returned, how pagination works, and how results can be used. It also disambiguates from template search, leaving no crucial gap for correct invocation.

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 100% with detailed parameter descriptions, so the description carries little additional parameter-level meaning. It reinforces that search criteria are broad and that the result can be a singular design or multiple results, but it does not add new semantics beyond the schema.

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 the specific verb and resource: 'Locate or browse the user's existing Canva designs' and explicitly excludes 'reusable templates,' distinguishing it from search-brand-templates. It also clarifies that it covers designs owned or shared, making its scope unmistakable.

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 explicit usage context: 'Use to find a single past presentation... or to discover multiple results based on search criteria.' It also provides a clear exclusion ('Not for locating reusable templates') and notes that returned design_ids can be used downstream, guiding the agent on when and how to use this tool.

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?

Annotations already establish readOnlyHint and non-destructive behavior; the description adds value by disclosing the output behavior: 'Returns matching folders and, when more results are available, a continuation token for the next page'. It also confirms the scope of owned/shared folders, but does not mention ordering or result limits beyond the schema.

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?

Four sentences, front-loaded with the core purpose and then exclusions and return behavior. There is no filler, and every sentence earns its place.

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 read-only search tool with annotations, 100% schema coverage on parameters, and no output schema, the description is complete: it covers scope, use cases, exclusions, and pagination. No essential information for choosing or calling it correctly is missing.

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 the baseline is 3; the description mostly restates concepts already in the schema (matching by names/tags, owned/shared scope, continuation token). It does not add meaningfully new parameter semantics beyond what the schema 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?

Description opens with a specific verb+resource: 'Find or browse Canva folders the user owns or that are shared with them'. It distinguishes itself from siblings by explicitly stating it is 'Not for finding designs, images, or subfolders', which separates it from search-designs and list-folder-items.

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?

It gives concrete use cases ('locate a project folder by name or tags', 'find a shared workspace', 'identify a folder before reviewing contents') and clear when-not-to-use guidance. It stops short of naming the sibling tool to choose instead, so the routing is slightly less explicit than a 5.

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?

Annotations declare readOnlyHint=false and destructiveHint=false, so it is known to be a mutating but non-destructive operation. The description adds the transactional nature ('draft transaction', 'same session') and what it returns (transaction_id and editable element data). It does not mention the need to later commit or cancel, but the transaction concept is adequately disclosed.

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 three sentences totaling about 60 words, with the core purpose front-loaded in the first sentence. Every sentence contributes: purpose, usage scenarios, and return value. No fluff or redundant phrasing.

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?

Given there is no output schema, the description covers what is returned (transaction_id and editable data). It does not spell out the transaction lifecycle (commit/cancel) or error conditions, but the sibling tools make the next steps predictable, and the description is sufficient for an agent to initiate the intended 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 coverage is 100% for both parameters (design_id and user_intent), and each has a clear description in the schema. The tool description does not add new parameter-specific guidance beyond reiterating that it returns element data, which is output-related. Since the schema already documents parameters, a baseline 3 is appropriate.

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 opens with a specific verb ('Prepare') and resource ('an existing Canva design'), then states the outcome ('opening a draft transaction'). It enumerates exact use cases (text, media, titles, formatting, autofill labels) and clarifies it is for preparing changes or inspecting elements, distinguishing it from read-only tools like get-design-content and from the commit/cancel siblings.

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 explicitly says 'Use to prepare changes...' and 'or inspect the editable text and media elements before changing them,' which gives clear when-to-use context. It does not explicitly name alternatives or exclusions, but the phrasing implies this is the prerequisite step before modification, and the sibling list makes the transaction flow obvious.

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?

Annotations already indicate readOnlyHint=false and destructiveHint=false, so it's a non-destructive write. The description adds meaningful context: it imports media, adds to library/uploads, returns a media_id, and does not place into a design. It also warns about URL accessibility, which is beyond the annotations. Slight gap: no mention of what happens on failure or whether it overwrites, but that's not critical.

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 four sentences, each earning its place: opening purpose, typical use cases, explicit constraints and exclusions, and return value. It is front-loaded with the core action and avoids fluff. Efficient and well-structured.

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 3-parameter tool with no output schema, the description covers the essentials: what it does, when to use it, constraints, and the return value (media_id). It also clarifies what it doesn't do. No critical missing information for an agent to call it correctly, though it could optionally mention error conditions or file type limitations.

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?

The input schema provides 100% description coverage for all three parameters, including detailed descriptions for 'url' and 'name'. The tool description largely reiterates the URL requirement and adds the return of media_id, but doesn't add substantial new meaning beyond the schema. Baseline of 3 is appropriate given the high schema coverage.

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 action and resource: 'Import media from an existing public URL into Canva.' It clearly differentiates itself from siblings by noting 'Does not place the imported media into a Canva design,' which distinguishes it from import-design-from-url. The verb 'import' and the resource 'media' are 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?

The description gives explicit guidance: 'Use to upload a publicly hosted image...' and 'Only call with a public HTTPS URL whose content is already publicly accessible. Do not use for local, private, or agent-generated files.' It also clarifies what the tool does not do (place into design). This is direct when-to-use and when-not-to-use guidance without requiring inference.

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