Canva MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation2/5
Multiple tools target the same action of creating presentations (create_presentation, create_markdown_presentation, generate_presentation_from_brief, create_autofilled_presentation, create_flyer), with descriptions that only partially differentiate them. Many tools are stubs marked 'Not implementable' or 'Not implemented,' which creates ambiguity about which tools are actually usable and what they do.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., list_presentations, create_presentation, export_presentation, get_export_job). There are no mixed conventions or unpredictable verb styles, making the naming highly predictable.
Tool Count2/5
The server exposes 28 tools, but a large portion are non-functional stubs or redundant creation variants. This overinflates the count relative to the actual working surface, making it heavier than needed for the core functionality and adding noise for agents.
Completeness2/5
The tool set covers creation, autofill, export, and import workflows, but lacks any meaningful editing or management capabilities—slide manipulation, text replacement, and sharing are all stubs. This leaves obvious gaps in the lifecycle of a presentation (e.g., no update/delete), causing dead ends for agents.
Average 3.2/5 across 28 of 28 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description honestly discloses that the tool is a non-functional stub due to a missing browser-automation dependency (e.g., Playwright). This goes beyond annotations and explicitly warns the agent that invoking it will fail, which is useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It omits all functional details and reads as a placeholder, not as a deliberately streamlined explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters and no output schema or annotations, the description is drastically incomplete. Even acknowledging it is a stub, it does not clarify the intended purpose, parameter meaning, or outcome, making it unusable for selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about the three required parameters (action, target, reason). With 0% schema coverage and no parameter descriptions, the agent has no clue what these strings mean or how to fill them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name implies a browser automation tool for Canva, but the description only states it is not implemented and does not define any actual functionality. There is no verb or resource described, leaving the agent unable to understand what the tool would do if it were available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or which alternative to choose instead. The description merely says it is not implemented, implicitly discouraging use, but does not name any sibling tools as substitutes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention synchronous vs. asynchronous execution, the waitForCompletion parameter, side effects, permissions, or the relationship to export jobs. This is a significant gap for a tool with an async workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified. Conciseness should not come at the cost of essential context. It lacks any enumeration of options, behavior, or usage, making it more an under-specification than a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (six parameters, multiple enums, a completion-waiting option) and the lack of an output schema, the description is completely inadequate. It fails to explain what the export produces, whether it returns the file or a job ID, or how it interacts with get_export_job. The description is far too minimal for the actual tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it adds no information about the six parameters. It doesn't explain the meaning of format, size, pages, exportQuality, or waitForCompletion. The description is entirely unhelpful for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Exports the presentation') and mentions a supported format, but it doesn't specify which formats or what the actual outcome is (e.g., file, job). It distinguishes somewhat from the name but not from sibling tools like get_export_job, and the phrase 'supported format' is vague without referencing the schema's enum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_export_job. No mention of prerequisites, typical scenarios, or exclusions. The description gives no context beyond a basic statement of function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool is not implemented, which is a key behavioral trait, but it does not detail what happens when called (e.g., error message, empty result). Since no annotations are provided, this partial transparency is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, front-loading the key 'Not implemented' message. However, it is under-specified as a tool description, lacking functional details. It earns its place as a clear status indicator but falls short of being a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no annotations or output schema, the description should provide more context about intended behavior and alternatives. It tells the agent the tool is not implemented, which is important, but it does not mention what this tool would typically do or suggest using another sibling. The description is incomplete for effective agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the input schema. With 0% schema description coverage, the description must compensate for parameter semantics, but it provides zero information about 'query', 'limit', or 'assetType' beyond basic schema constraints. The tool's non-implementation status does not help understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Not implemented', which communicates the tool's non-functionality but does not describe what the tool would do if implemented. It fails to define a clear purpose beyond negating the implied search functionality. The title 'Search Assets' and name suggest a search operation, but the description does not confirm any actual behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description only says no endpoint is wired up, without specifying when to use or avoid this tool or suggesting any alternative sibling tools. The agent is left without any direction on how to handle asset searching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It only conveys that this is a creation operation (implying a write), but it does not explain side effects, permissions, rate limits, or whether it overwrites or creates new. The single sentence provides minimal behavioral context beyond the obvious action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the core purpose. It avoids verbosity and all words contribute to the meaning, making it structurally efficient. However, its brevity comes at the cost of missing necessary details, but that is a completeness issue rather than a conciseness one.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, no output schema, and multiple sibling creation tools, this description is severely incomplete. It lacks information about return values, how to choose between template and outline, parameter relationships, and when to use this tool over alternatives. The description is far from sufficient for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It mentions 'template or outline' but does not map these to templateId, outlineId, or assetId. The 5 parameters (title, assetId, language, outlineId, templateId) remain unexplained, leaving the agent without guidance on how to specify the template or outline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates a new Canva presentation') and the source ('from template or outline'), making the tool's purpose understandable. However, it does not explicitly differentiate from sibling tools like create_autofilled_presentation or generate_presentation_from_brief, so it lacks strong sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention exclusions, prerequisites, or scenarios where a different tool (e.g., create_markdown_presentation) would be more appropriate. The agent is left to infer usage from the generic wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states a high-level action. It does not indicate whether the operation is read-only, whether it has side effects, what it returns, or any required setup. This leaves the agent without important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it compact and easy to parse. However, its brevity borders on under-specification, so it loses one point for lacking structured detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations, yet the description provides no additional context about how 'the brief' is used, what the selection process entails, or how the result is returned. This is extremely incomplete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero documentation for its 5 parameters, and the description does not compensate by explaining any parameter meanings. Terms like 'style', 'audience', 'brandKitId', and 'aspectRatio' are left undefined, so the agent has no semantic guidance for filling them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('selects') and resource ('Canva template'), indicating the tool's function. However, it does not explicitly differentiate itself from sibling tools like list_brand_templates, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The phrase 'for the brief' implies a use case, but it does not describe prerequisites or mention any sibling tools that could be alternatives, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Lists') but doesn't disclose pagination behavior via the continuation parameter, sorting options, or rate limits. It also doesn't describe the return structure or any error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loaded with the verb 'Lists.' While concise, it omits important context, so it isn't as helpful as a concise description that includes key behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, this description is severely under-specified. It doesn't mention the continuation token for pagination, filtering capabilities, or the response format. The lack of behavioral context makes it hard to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 0% description coverage. The description fails to mention any parameters (limit, query, sortBy, dataset, ownership, continuation), leaving their meaning and allowed values entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and resource ('Canva brand templates'), and adds context ('available to the authorized user'). It distinguishes from siblings like list_presentations by focusing on brand templates, though it doesn't explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_assets or list_presentations. No usage scenarios, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It fails to mention whether the operation has side effects, whether it requires any special permissions, or what the output structure looks like. It only states that it generates a plan, leaving the behavioral profile largely unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, given the tool's complexity (7 parameters), the description is under-specified and could benefit from additional context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and 7 parameters, yet the description is only one sentence. It does not explain the meaning of a 'brief,' what the generated plan will contain, or how to interpret the required inputs. This is insufficient for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not compensate by explaining what a 'brief' comprises or what each parameter (topic, objective, audience, tone, etc.) contributes. The description adds no semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'generates' with the resource 'presentation plan' and clarifies the input source 'from a brief.' This distinguishes it from sibling tools like create_presentation and generate_presentation_from_brief by emphasizing the outline/plan output rather than the full presentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alternatives such as generate_presentation_from_brief or create_presentation. The description only states what it does, without providing any contextual triggers or criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the absence of annotations, the description carries the full burden of behavioral disclosure. It explicitly states the API has no endpoint for the operation, making it evident that invoking this tool will not succeed. This is a significant behavioral trait transparently disclosed, though it does not specify the exact failure mode (e.g., error vs. no-op).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly conveys the tool's non-implementable status. It is appropriately sized and front-loaded, containing no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that cannot be implemented, the description adequately warns the agent to avoid invocation, which is a critical piece of context. However, it does not provide guidance on alternative tools or what to do instead, leaving the agent without a complete resolution path. Given the 6 parameters and no output schema, this is a minimal-but-sufficient warning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about any of the 6 parameters. With 0% schema description coverage, the description was expected to compensate by explaining parameter semantics, but it does not. The parameters (e.g., body, merge, title) remain entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state a specific action or resource; instead, it declares the tool 'Not implementable' with a technical reason. This clearly signals the tool cannot perform its intended function, but it lacks a verb+resource purpose statement and does not distinguish it from sibling tools beyond declaring uselessness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should never be used, but it provides no explicit when-to-use guidance and does not mention alternative tools (e.g., replace_text_placeholders, add_slide) that could achieve the intended functionality. The exclusion is clear, but the context of when to use alternatives is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description honestly discloses that the tool does not work and explains why (no API endpoint). This is valuable transparency, but it doesn't describe any fallback behavior or error handling, so it's only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that directly states the non-implementation status. It is efficient and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-implemented tool, the description explains why it's unavailable, which is the most important context. However, it lacks guidance on alternatives or expected behavior if called, so it's not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 2 parameters with 0% description coverage, and the description does not mention them at all. It adds no meaning to presentationId or checks beyond their names in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the intended purpose ('validate an existing design against') but immediately negates it with 'Not implemented'. So the purpose is clear but the tool is non-functional. It does not fully distinguish from siblings since it's just a warning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly says the tool is not implemented, implying it should not be used, but provides no guidance on what to use instead or when this might be relevant. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly discloses that the tool cannot be implemented due to a missing API endpoint, which is a critical behavioral trait. It stops short of specifying what happens at call time (e.g., an error), but the core limitation is transparently stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that delivers the essential message ('Not implementable') with a clear reason. It is appropriately sized for its purpose and contains no unnecessary words, making it an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-implementable tool, the description adequately communicates the key limitation and prevents the agent from attempting a doomed call. However, it is incomplete in that it does not suggest an alternative tool, does not explain the parameters, and does not state the expected failure mode. Given the context of sibling tools like update_slide_content, the description could be more useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two required parameters with zero schema description coverage, and the tool description does not mention them at all. It does not explain what presentationId or replacements would mean or why they cannot be used. The description adds no value to the parameters beyond the raw schema, leaving the agent without semantic guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what the tool does; it only states that it cannot be implemented. The name implies the intended function (replacing text placeholders), but the description fails to describe the operation itself, leaving the tool's purpose effectively unaddressed in a functional sense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Not implementable,' providing a clear when-not-to-use directive and highlighting that the tool should never be invoked. However, it does not mention any alternative tools (e.g., update_slide_content) that could achieve the goal, so it misses the alternatives component of ideal usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function, without mentioning pagination (continuation parameter), sorting behavior, query filtering, or whether the operation is read-only. This lack of detail leaves significant behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no verbosity, which is efficient. However, it is overly terse given the tool's five parameters, omitting critical usage details. It is concise but at the expense of completeness, earning a mid-range score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no annotations, no output schema, and the description is minimal. It fails to explain return format, pagination via continuation token, or how query and sortBy behave. The context is far too thin for an agent to fully understand and correctly invoke the tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly explains the folderId parameter by mentioning 'defaulting to root', but it does not clarify limit, query, sortBy, or continuation. These parameters remain underspecified, requiring the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and resource ('Canva presentations') with an added scope ('in a folder, defaulting to root'). This differentiates it from sibling tools like list_brand_templates (which lists brand templates) and search_assets (which searches assets broadly).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_assets or list_brand_templates. There is no mention of suitable contexts, exclusions, or comparisons, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description openly discloses that no sharing/permissions endpoint exists and the tool is not wired up. This is valuable behavioral context beyond any annotations, effectively warning the agent that calls will fail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly communicates the non-implementation status. It is concise and front-loaded with the key warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is a stub, the description adequately conveys it should not be used. It doesn't explain intended behavior or error handling, but for an unimplemented tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about presentationId or access parameters. The agent must rely solely on the schema, which lacks explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Not implemented' rather than describing what the tool does. It provides no verb or resource, only a negative status. The title implies sharing, but the description does not confirm any actual functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is not implemented, making it clear it should not be used. This provides a strong when-not guideline, even though no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'creates' a design, but omits critical details such as potential async execution (hinted by the waitForCompletion parameter), side effects, authorization requirements, or risk profile. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently conveys the core action and resource, making it easy to parse and remember. The brevity is appropriate for a tool whose complexity is not matched by the description, but the sentence itself is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, nested objects, no output schema, and no annotations, the one-sentence description is inadequate. It fails to explain the data contract, the role of the 'title' parameter, whether the operation is asynchronous, or how this tool relates to sibling tools. A minimal viable description for this tool would require more context to ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives partial meaning to 'brandTemplateId' and 'data' via 'brand template' and 'Autofill data,' but does not explain the purpose or format of 'title' or 'waitForCompletion.' The 'data' object's structure is also unspecified, leaving important parameter semantics unresolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Canva design from a brand template using Autofill data. This specific verb+resource+method distinguishes it from sibling tools like create_presentation or generate_presentation_from_brief, which do not involve Autofill data or brand templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case of filling a brand template with Autofill data, but it does not explicitly state when to prefer this tool over alternatives like create_presentation or apply_brand_kit. There is no mention of prerequisites, exclusions, or when not to use it, so the guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the main actions (building PPTX and optionally importing to Canva) but omits important traits such as the default values of importToCanva and waitForCompletion, file output behavior, potential authentication requirements, and whether the operation is long-running. This lack of detail makes it difficult for the agent to anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the primary purpose and optional secondary action. It contains no filler or redundant information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is too minimal to be complete. It does not specify return values, error scenarios, or the effect of the default parameters (e.g., importToCanva defaults to true), meaning the agent may not fully understand the tool's behavior without additional research.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for parameter meaning. It only clarifies markdownPath indirectly and mentions the optional Canva import, but it does not explain the semantics of parameters like fontStyle (enum values), outputPath, title, or waitForCompletion. This leaves the agent without necessary context to set parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's core function: 'Builds a styled PPTX from a markdown file and optionally imports it into Canva.' This specific verb-resource pairing (builds + PPTX) with the markdown source distinguishes it from sibling tools like create_presentation or create_presentation_from_brief, which likely handle different input types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a markdown file needs to be converted into a styled presentation, but it does not explicitly state when to use this tool versus alternatives such as create_presentation or create_presentation_from_brief. No exclusions or alternative tool references are provided, leaving the agent to infer the appropriate context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'returns' the fields, implying read-only behavior, but does not disclose potential errors, authentication requirements, or any other side effects. The output structure is also unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose ('Returns...') and contains zero wasted words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description is minimally complete for a basic get operation. However, it lacks any context about how the returned dataset fields are meant to be used, such as in autofilling presentations, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter brandTemplateId is referenced in the description as 'a Canva brand template', which adds a bit of context beyond the schema's bare property name. However, the description doesn't explain where to obtain the ID or any format requirements, leaving the 0% schema coverage partially uncompensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'the autofillable dataset fields for a Canva brand template', using a specific verb and resource. This distinguishes it from siblings like list_brand_templates (which lists templates) and create_autofilled_presentation (which consumes the dataset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that it's a prerequisite for create_autofilled_presentation or any other contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the read-only nature of retrieving a status but provides no additional context about the response structure, possible status values, error scenarios, or whether the operation is immediate or may take time. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the verb and object. It is appropriately concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool with one parameter and no output schema, the description covers the basic purpose but lacks details on the return format or how it fits into the export workflow. Sibling tools like export_presentation and get_import_job suggest a related context, but the description doesn't connect them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention the jobId parameter. The parameter name is self-explanatory, but the description fails to add any meaning beyond what the schema already shows, leaving the agent to infer its purpose from the name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current status of a Canva export job, using a specific verb ('retrieves') and resource ('export job'). It distinguishes from sibling tools like get_import_job by specifying 'export'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention that it should be used after initiating an export via export_presentation, nor does it describe any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read-only operation through 'Retrieves', but does not disclose what the response contains, whether the job can be polled, or any error behavior. The disclosure is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the action and resource without any redundancy. It is front-loaded and contains no unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly adequate, but it lacks information about the expected return status values and how the jobId is obtained. It also does not reference related tools like get_export_job, leaving some contextual ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes jobId with type and minLength but no description, and schema description coverage is 0%. The description does not elaborate on the jobId parameter, such as where it comes from or its format, relying entirely on the parameter name for meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieves' and the resource 'current status of a Canva import job', which precisely identifies the tool's function. It also distinguishes the tool from get_export_job by specifying 'import job' rather than 'export job'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_export_job, nor does it mention any prerequisites for obtaining a jobId. Usage context is entirely implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the key behavioral trait that the API lacks an endpoint, making any call to this tool fail. This is critical and goes beyond the schema. However, it does not specify the exact error behavior or response, so it is not maximally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the essential warning. It is concise, front-loaded, and contains no unnecessary words, making it highly efficient for the agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool explicitly declared non-implementable, the description covers the most important fact: it cannot be used. However, it omits potential alternative tools and does not explain why the tool exists, which leaves a small gap. Given the simplicity of the schema and lack of output schema, the description is mostly complete for preventing misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the four parameters (presentationId, slideId, assetId, placementHint), and schema coverage is 0%. Since the tool is non-functional, parameters are irrelevant, but the description still fails to compensate for the lack of schema descriptions, leaving the agent with no semantic understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly conveys the intended operation (insert an image into an existing design's slide) and immediately states it cannot be performed because the Canva Connect API lacks an endpoint. This makes it unambiguous that the tool is non-functional, but it does not explicitly compare with sibling tools beyond the negative statement, so it stops short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-not-to-use directive ('Not implementable'), which is explicit. However, it provides no alternatives or guidance on how to achieve the desired outcome through a different tool, such as update_slide_content. Thus the usage guidance is present but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states 'uploads' but does not mention potential side effects (e.g., whether the upload is idempotent, whether it overwrites existing assets), prerequisites (e.g., authentication, file existence), or behavior related to async operations (despite the waitForCompletion parameter). This is a significant gap for a side-effecting operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb, resource, and purpose. There is no wasted wording, and every part of the sentence contributes to understanding the tool. It is appropriately sized for a straightforward upload operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, and no annotations, the description is insufficient for an agent to fully understand the tool. It omits details on return values, parameter semantics, and side effects. While the operation is simple, the lack of structured metadata means the description should compensate but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain any parameters. Only filePath is vaguely implied by 'local image file.' The parameters name, mimeType, and waitForCompletion are completely undocumented in both the schema and the description. This is inadequate for a tool with four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (upload), the resource (local image file to Canva), and the specific purpose (reusable asset for autofill image fields). It distinguishes itself from sibling tools like insert_image (which inserts into a presentation) and search_assets (which searches existing assets) by focusing on the upload-as-reusable-asset use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: it's for uploading a local image to be used in autofill image fields. While it doesn't explicitly mention alternatives or exclusions, the purpose statement implicitly guides the agent on when to choose this tool over siblings like insert_image or search_assets. It lacks explicit when-not-to-use guidance but is not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool performs two sequential actions (outline creation and Autofill-based presentation generation) and depends on a brand template. However, it doesn't mention potential asynchronous behavior (though waitForCompletion parameter hints at this), failure modes when no template is available, or any return value details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 17 words, front-loaded with the primary verb and containing no extraneous or repetitive content. Every phrase adds meaningful information about the tool's behavior and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 11 parameters, no output schema, and no annotations. The description is too minimal to guide correct invocation. It does not explain how parameters like slideCount, datasetOverrides, or waitForCompletion factor into the outcome, nor does it clarify the relationship to sibling tools such as create_presentation_outline or create_autofilled_presentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain any of the 11 parameters, including the required ones (topic, objective, audience) which are the core of the 'brief'. The description's mention of 'brief' offers only a vague connection to the input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Builds an outline and creates a Canva presentation'), a specific mechanism ('using Autofill'), and a conditional scope ('when a brand template is available'). This clearly distinguishes it from sibling tools like create_presentation_outline and create_autofilled_presentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the intended use case: generate a presentation from a brief, using a brand template. The phrase 'when a brand template is available' provides a clear condition for when this tool is appropriate, though it does not explicitly name alternative tools for cases where no template exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone carries the critical behavioral fact that calling this tool will not work. It clearly discloses the API limitation, but it does not specify what happens if actually invoked (e.g., an error message). The statement is sufficient to prevent misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one sentence that immediately conveys non-implementability. It is perfectly concise and front-loaded with the key warning, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool declared non-implementable, the description is complete in stating its unusability. It lacks alternative recommendations, but the list of sibling tools partially compensates. Given the tool's non-functionality, additional parameter or return details would be pointless.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description makes no reference to the five schema parameters, and schema description coverage is 0%. Since the tool is non-implementable, parameter semantics are moot, but the description adds no meaning beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is not implementable due to a missing API endpoint, which sets expectations and distinguishes it from working sibling tools. However, it does not describe an intended function, making it more of a placeholder than a standard tool purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Not implementable', telling the agent this tool should never be used. It provides a clear when-not but does not point to any alternative tools for chart insertion, though sibling names like insert_image suggest related functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It openly states that the tool cannot be implemented and why, making it perfectly transparent that calling this tool will not perform any restyling. This is a high-value disclosure beyond what any structured field could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key message 'Not implementable', and contains no filler. It is exemplary in efficiency and clarity for a stub tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is declared non-implementable, the description is fully complete: it tells the agent everything needed to decide not to use it. There is no output schema or complex behavior to document, so the one-sentence warning is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It only vaguely alludes to 'colors/fonts' which partially maps to primaryColor, secondaryColor, and fontFamily, but it does not explain individual parameters. Since the tool is non-implementable, the lack of parameter details is partly excusable, but it still fails to add meaningful semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is not implementable and specifies what it would have done ('restyle colors/fonts on an existing design'), which immediately distinguishes it from functional siblings. However, it lacks a positive verb describing an actual capability, so it does not fully meet the 'specific verb+resource' criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent the tool should not be used ('Not implementable'), providing a clear when-not-to-use signal. However, it offers no alternative tools for achieving the desired restyling, so the guidance is incomplete compared to a 5-level example with explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses core behavior (builds PPTX, optional import to Canva) but omits side effects like file creation location, Canva account modifications, or required permissions. The mention of 'optionally imports' adds some transparency, but not enough for a creation tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and immediately offering an alternative. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no output schema, and no annotations, this short description is insufficient. It covers high-level behavior but omits parameter details, prerequisites, return values, and edge cases. The alternative-tool mention adds some context, but the overall completeness is low for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain any of the 14 parameters. It only hints at styling ('styled single-page flyer') and optional import, but gives no meaning for headline, size, fontStyle, importToCanva, etc. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Builds a styled single-page flyer (PPTX)' and optionally imports it into Canva. This specific verb+resource combination distinguishes it from sibling tools that target presentations or autofill flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides an alternative path: 'If you already have a flyer-shaped Brand Template in Canva, generate_presentation_from_brief + get_brand_template_dataset (autofill) can target it directly instead.' This tells the agent exactly when to prefer other tools, which is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Returns runtime readiness' which implies a read-only operation, but does not clarify what readiness includes (e.g., dependencies, latency) or any potential side effects. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word earns its place, with no redundancy or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless health-check tool, the description is largely complete for invocation purposes. However, it lacks details about the return format (e.g., boolean, status object) since no output schema exists, which is a minor gap for a tool that could report richer state. Overall, it is sufficient for a simple health check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema explicitly documents this with an empty properties object. The description adds no parameter details because none exist, matching the baseline for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and a clear resource ('runtime readiness for the Canva MCP server'), which unambiguously communicates the tool's function. It is easily distinguished from sibling tools that perform editing, creation, or export operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to check server readiness but does not explicitly state when to use it, nor does it mention alternatives or exclusion criteria. Given the trivial nature and lack of sibling health-check tools, this is acceptable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the key behavioral trait (non-functional stub) and the reason (missing API endpoint), which is transparent and prevents the agent from expecting a result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys all essential information without any fluff. It is perfectly sized for the purpose of declaring non-implementability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that is not implementable, this description is fully complete. It tells the agent not to use it and why, and no further details about parameters, return values, or behavior are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about the parameters (presentationId, slides). Since schema coverage is 0% and the description does not compensate, no meaning is added beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is not implementable and gives the reason (no API endpoint), making its non-functional status unambiguous. This clearly distinguishes it from all sibling tools that are implementable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'when not to use' guidance: it cannot be implemented, so the agent should never select it. This is the clearest possible usage instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It fully discloses that any invocation will fail due to missing API support, eliminating any false expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that delivers the essential warning with zero wasted words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that is not implemented, the description is completely sufficient. It tells the agent everything it needs to know: do not call this. No further details about return values or side effects are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the input schema. Schema coverage is 0%, and none of the three parameters (tone, slideId, presentationId) are explained. Since the tool is non-functional, this is notable but still a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool is not implemented and why (no API endpoint exists). This clearly communicates what the tool does (nothing) and distinguishes it from all other working tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it is not implemented, so the agent should not attempt to use it. This is more direct than most usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It clearly states that invocation will fail due to missing API support, giving the agent full transparency about the tool's non-functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence conveys the entire message with zero wasted words. It is front-loaded with the critical 'Not implementable' phrase, making it immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-functional tool, the description is complete: it states impossibility, the reason, and implies the tool should not be invoked. No additional details about return values or behavior are necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no meaning for the two parameters (presentationId, orderedSlideIds). Schema description coverage is 0%, and the description does nothing to compensate, even though the tool's non-functional status makes parameter details less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description unequivocally states that the tool is not implementable, specifying the exact resource (Canva Connect API) and missing endpoint. This clearly distinguishes it from sibling tools like add_slide and update_slide_content, which are functional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit when-not guideline: the tool should never be used because no API endpoint exists. While it doesn't name alternatives, the exclusion is absolute and unambiguous, which is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fully discloses that the tool has no backend implementation and will not work, giving the agent complete transparency about its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with 'Not implementable,' which immediately conveys the critical constraint. There is zero wasted wording, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-implementable tool, the description is complete: it states the limitation, and since there is no output schema or functional behavior, no further details are needed. The agent knows everything required to avoid misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters, but it renders them irrelevant by stating the tool is not implementable. This compensates for the 0% schema description coverage by telling the agent not to attempt invocation, so parameter meanings are unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the intended operation (add slide) and explicitly says it is not implementable due to the Canva Connect API lacking an endpoint. This unambiguously tells the agent what the tool would do but that it is non-functional. It distinguishes itself from siblings by being the only one marked as non-implementable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Not implementable' is an explicit instruction to never use this tool under any circumstances, providing a clear when-not condition. It does not name alternatives, but the exclusion is absolute, which is highly actionable guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![canvas-mcp MCP server](https://glama.ai/mcp/servers/moisesbritez92/canvas-mcp/badges/card.svg)](https://glama.ai/mcp/servers/moisesbritez92/canvas-mcp)

Score Badge

Copy to your README.md:

[![canvas-mcp MCP server](https://glama.ai/mcp/servers/moisesbritez92/canvas-mcp/badges/score.svg)](https://glama.ai/mcp/servers/moisesbritez92/canvas-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/moisesbritez92/canvas-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server